Thread: an interesting bug...

So, I was coding today and banging my head against the wall as usual. I have been trying to multithread my code to take advantage of multi-core processors.

It turns out I have been leaving a lot of data open and having all sorts of file parsing errors that I hadn't anticipated. I learned about this because threads which read files wouldn't die.

I guess sometimes learning a new programming concept, though it complicates things, can help you find bugs! Makes me happy... =]

What was the bug, actually?
One of the things that will never stop to amaze me about programming, is the feeling of achievement even after long periods of frustration. A bug can have me spend a whole day looking at the debugger to the point exasperation. But the precise moment the cause is found and the bug corrected, I always get a strong feeling of accomplishment and all the previous frustration is forgotten.

BTW, was this just you experimenting? Or is there a reason why you don't want to use some asynchronous I/O library?

@Mario

The bug was that in my Word class I use a static TreeMap so I can do comparisions between integer keys instead of Strings, which is much much faster. Worked like a charm in a single-thread model, but failed miserably in a multithread model when multiple threads tried to IO to the map.

I have thought about another topology where I have a thread which does IO, and then threads which process...

It turns out there is a lot to synchronize, and I'm at this point 'tightening up' my synchronization to only be around write commands for shared data. 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?

@Bubba

I had cut my teeth in procedural programming, then OOP (which I still don't feel touch-and-go with, there are a few things I tend not to use...), and now this multithreading business is causing me to grow gray hairs... But, changes in architecture mean this needs to be learned, and I like it...

I guess what I'm saying is, as I'm sure you older programmers have learned, that this is the first time I can directly see an effect of the changing technology that I feel I need to 'keep up with'. 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...

Originally Posted by doubleanti

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)