tag:blogger.com,1999:blog-1879770534244304287.post1088477143307114960..comments2007-07-10T10:27:23.402+01:00Neil Wilsonhttp://www.blogger.com/profile/11565959939525324309noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-1879770534244304287.post-76264780937174129392007-06-10T07:18:00.000+01:002007-06-10T07:18:00.000+01:00For me, I'd prefer micro-processes. If the O/S, compiler or run-time can't do it automatically, you shouldn't bother.<BR/><BR/>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.Neil Wilsonhttp://www.blogger.com/profile/18178155357632397049noreply@blogger.comtag:blogger.com,1999:blog-1879770534244304287.post-57726040258971541852007-06-10T06:15:00.000+01:002007-06-10T06:15:00.000+01:00naa ... it's an event driven world out there and where would we all be without threading?<BR/><BR/>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.<BR/><BR/>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)!<BR/><BR/>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.<BR/><BR/>Languages like Occum had a lot of promise at one time but seem to have gone off the point somewhat.<BR/><BR/>Anyhow, all the best.<BR/>Shaken not Stired.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1879770534244304287.post-45669593401864800002007-06-10T06:13:00.000+01:002007-06-10T06:13:00.000+01:00naa ... it's an event driven world out there and where would we all be without threading?<BR/><BR/>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.<BR/><BR/>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)!<BR/><BR/>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.<BR/><BR/>Languages like Occum had a lot of promise at one time but seem to have gone off the point somewhat.<BR/><BR/>Anyhow, all the best.<BR/>Shaken not Stired.Anonymousnoreply@blogger.com