Quote Originally Posted by doubleanti View Post
Am I right in thinking that the only things that need to be synchronized are when writing to shared objects? And that reading is OK in general from several threads?
Depends on the exact nature of what you are doing, but generally speaking threaded IO is to be avoided. Reading or writing shouldn't make a difference. This is so, because, if you think about it, there's really only one path to the hard drive. Threaded reading or writing operations won't make a difference since the disk head will still operate in a sequential manner.

Of course, I'm speaking of using several threads to read from, or write to, the disk. In case you want a thread to do it while other threads do other processing tasks not related to disk IO, that should be fine as long as it's not complicated. What you want to avoid is the use of multiple threads tasked with reading or writing.

In any case, whenever there's a need to "multitask" disk access (be it through multiple threads or a single separate thread), you should turn your attention to asynchronous IO instead. These libraries present you with a model that handles exactly the complications presented with synchronization. Most notably the ability to easily define which threads are meant to keep executing, and which ones are meant to wait for disk IO to complete.

I'm hoping that in the future they make this sort of thing transparent to the programmer... =] It adds a dimension of complexity that makes programming even more of an art...
You and I mate. You and I.

Personally I place the blame on the threading model adopted by C, C++ and many other languages. I'm a critic of my beloved language, on this aspect.

Other threading models exist. Most notably (and the one I always shamefully promote) is the Actor model presented in programming languages like Erlang (see links below). In fact, I've experimented before with the possibility of interfacing my multithreaded programming in Erlang with my C++, bypassing entirely the need to code for C++ threads. Interfaces like Jinterface, tinch++, EPAPI, or Erlang's own erl_nif C library, offer solutions in this regard. But it's all a bit experimental yet and not really advisable for production code... or practical for large and complex projects.

So, my real hope is that, one day, somehow we realize that the Thread model is bonkers and we are insane for trying to code multitasking this way. Then highly qualified library writers will see to it to abstract the whole thing away from us programmers and develop good quality libraries that present us with other models. My personal vote, the Actor model.

Links:
An introduction to the "The problem with threads" paper: Stay Hungry, Stay Foolish - The Problem with Threads | …on Coding | Algorithm.com.au

"The Problem with Threads" paper: http://www.eecs.berkeley.edu/Pubs/Te...ECS-2006-1.pdf (pdf link)