I find Rails and Ruby so nice to use because they keep things very simple and deterministic. So when the "let's get Rails thread safe" brigade start up, I'm happy to point out that things are a lot better if you don't go there. (In fact I'd like the synchronisation point in Mongrel taken out because it causes unnecessary queueing problems if your server becomes overloaded).
That argument has kicked off again with a DHH post this morning and a response about why threads are vital to the future of Ruby and Rails.
Personally I like the quote from Professor Lee's 'The Problem with Threads' and I think it is highly appropriate to this debate.
... a folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane. Were they sane, they could not understand their programs.
Posts
3 comments:
naa ... it's an event driven world out there and where would we all be without threading?
Get your head around synchronisation objects. They are what make multi-threading deterministic. Most OS's are rich in such objects - semaphores, events, etc. any shoulder tapper will do.
I do though agree with Ted to some extent. Yes programmers need to know how to do this properly and it involves another layer of complexity, etc. Unfortunately most avoid it like the plague, even in GUI interfaces. Break an hour glass near you today, multi-thread (anyone writing polling loops will be shot)!
My take on this has always been that compilers need to do loop and flow analysis to automatically isolate and co-ordinate threading at a much lower level. The problem with that has always been the runtime overhead of co-ordination. But with massively multicore processors on the horizon, such an approach could be made to pay dividends. However, I'd call that micro-threading, you'd still need the manual stuff higher up.
Languages like Occum had a lot of promise at one time but seem to have gone off the point somewhat.
Anyhow, all the best.
Shaken not Stired.
naa ... it's an event driven world out there and where would we all be without threading?
Get your head around synchronisation objects. They are what make multi-threading deterministic. Most OS's are rich in such objects - semaphores, events, etc. any shoulder tapper will do.
I do though agree with Ted to some extent. Yes programmers need to know how to do this properly and it involves another layer of complexity, etc. Unfortunately most avoid it like the plague, even in GUI interfaces. Break an hour glass near you today, multi-thread (anyone writing polling loops will be shot)!
My take on this has always been that compilers need to do loop and flow analysis to automatically isolate and co-ordinate threading at a much lower level. The problem with that has always been the runtime overhead of co-ordination. But with massively multicore processors on the horizon, such an approach could be made to pay dividends. However, I'd call that micro-threading, you'd still need the manual stuff higher up.
Languages like Occum had a lot of promise at one time but seem to have gone off the point somewhat.
Anyhow, all the best.
Shaken not Stired.
For me, I'd prefer micro-processes. If the O/S, compiler or run-time can't do it automatically, you shouldn't bother.
Essentially the synchronisation points in the O/S are too low-level. When I see a reliable message queue and a transactional filesystem I'll reconsider.
Post a Comment