thread synchronization

[codec]

Just a quick question...

If I have a console app with multiple threads and more than one thread prints status information in a log style to the console output using printf would I need to enclose any printf statements within a critical section to avoid a mix of two messages being printed to the screen if two threads happened to printf at exactly the same time?

I haven't had it occur yet as I'm sure it would be quite a rare occurence but I was wondering, is it actually possible for that to happen?

I guess the same goes for outputing to a log file using the stdio functions.

tia

Daniel.

[Stoned_Coder]

Anytime you have the possibility of a collision like that you should use some form of synchronisation.

[Speedy5]

I don't think its possible but check your library's documentation. They should be labeled "thread-safe" or "not thread-safe." If they're not labeled at all, best bet on that its not since the developers didn't have threads in mind when making it. Most of the C/C++ library is not-thread safe as they only suggest one thread being executed (UNIX style I guess, one thread per process).

[Polymorphic OOP]

The language itself is really oblivious to threading because that's something that's heavily os dependant and also would limit c++ to just multithreading os's (unless the implementor of the compiler wants a lot more work and the os allows it ). The only thing that really shows they acknowledge threading is volatile.

[Fordy]

Originally posted by Speedy5
I don't think its possible but check your library's documentation. They should be labeled "thread-safe" or "not thread-safe." If they're not labeled at all, best bet on that its not since the developers didn't have threads in mind when making it. Most of the C/C++ library is not-thread safe as they only suggest one thread being executed (UNIX style I guess, one thread per process).

Thread safety is not the issue here...that usually relates to how the library has been implemented (ie using static buffers for multiple threads or relating a buffer to a specific thread)......

The problem is that there's no guarantee that any function can complete without being preempted unless you use one of the OS's mechanisms to control syncronisation.......so 2 calls (1 from each thread) printing "Hello World" might actually print "HellHello WorldoWorld"......this isnt allways the case, but it certianly is possible.....best bet, wherever 2 threads compete for a resource (even screen access) use a form of syncronisation

[codec]

thanks for the really helpful replys people. Much appreciated, I don't know where I'd be without help from people like you.

Later

Dan

[Speedy5]

Actually, Fordy, what we mean by thread safety is this:

1) Not using global buffers (static)
2) Locking the device/stream being used so that the ouput/input is uninterrupted. That way you can avoid "HellHello World World". In Java, this can be achieved to some degree using the syncronized keyword. .NET also has a similar feature.
3) etc

[kuphryn]

I think thread-safe is a design and implementation issue and should not rely on programming language or OS. Yes, an Windows and Linux provide a foundation for multithreads and multiprocesses. However, you are responsible for data synchronization.

Kuphryn