Synchronized StreamWriter - Is Flush ThreadSafe?

[Spam Catcher]

Hi all,

I'm accessing a synchronized Streamwriter from potentially several threads
to do some logging. Is the Flush command threadsafe too? Should I single
thread the Flush command or will the Synchronized streamwriter handle that
for me?

Thanks!

[Robin Tucker]

How are you writing to the log? I have public methods that are synclocked
on the log instance for writing in my class. You can also make the stream
auto-flush by default which is handy.

[Spam Catcher]

"Robin Tucker" <rt******@hotma il.comwrote in
news:f4******** ***********@new s.demon.co.uk:

>
How are you writing to the log? I have public methods that are
synclocked on the log instance for writing in my class. You can also
make the stream auto-flush by default which is handy.

The Synchronized Stream doesn't seem to support Auto-Flush.

I'm not synclocking the StreamReader because I heard it is still "unsafe".
Rather I'm using the thread-safe synchronized wrapper.

So I like to know if the threadsafe wrapper wraps everything ... or just
..write.

[Robin Tucker]

No I mean you have a class that wraps the stream and synclock that, so
writers are never accessing the stream directly. It is privately
encapsulated. For example, instead of writing Debug.Writeline (), the coder
will use MyTracer.WriteL ine (), where MyTracer is your accessor class that
does the synclock.

[Spam Catcher]

"Robin Tucker" <rt******@hotma il.comwrote in
news:f4******** ***********@new s.demon.co.uk:

>
No I mean you have a class that wraps the stream and synclock that, so
writers are never accessing the stream directly. It is privately
encapsulated. For example, instead of writing Debug.Writeline (), the
coder will use MyTracer.WriteL ine (), where MyTracer is your accessor
class that does the synclock.

I could do that - but the Synchronized Stream is SUPPOSED to be threadsafe.
So I'm just trying to confirm the fact about the .flush.

There's no sense in rewrapping a threadsafe class right?

[Robin Tucker]

"Spam Catcher" <sp**********@r ogers.comwrote in message
news:Xn******** *************** ***********@127 .0.0.1...

"Robin Tucker" <rt******@hotma il.comwrote in
news:f4******** ***********@new s.demon.co.uk:

>>
No I mean you have a class that wraps the stream and synclock that, so
writers are never accessing the stream directly. It is privately
encapsulated . For example, instead of writing Debug.Writeline (), the
coder will use MyTracer.WriteL ine (), where MyTracer is your accessor
class that does the synclock.

I could do that - but the Synchronized Stream is SUPPOSED to be
threadsafe.
So I'm just trying to confirm the fact about the .flush.

There's no sense in rewrapping a threadsafe class right?

Well that depends on what else you are doing with the stream. If it's nout,
then you should be fine with it.