Fwd: native threads

Ned Konz ned at squeakland.org
Sat Apr 16 19:47:33 UTC 2005


On Thursday 14 April 2005 12:15 pm, Ramiro Diaz Trepat wrote:
> As you can see, I am not a big theorist, but if I don't remember
> wrong, you cannot assume anything about the order in which threads
> will be executed or when will your thread be preempted when writing
> multithreded code.  And if you have to enforce or assure some
> situation, you have to use semaphores or something equivalent.  And
> hence you should get similar results in all platforms.
> Again, I am a manager and have not coded for production software in a
> while, so I know I might be missing something big.  I'm just trying to
> use common sense.

Using Semaphores or Monitors in application-level code is a symptom of 
irresponsible design.

Almost no one can get a multi-threaded application that uses more than one 
Semaphore to work reliably, regardless of the threading model in place. And 
it shouldn't require geniuses to make concurrency work. There have been a 
number of high-profile embedded systems failures because of bad concurrency 
design (search for "priority inversion" or "semaphore deadlock" for more 
background).

For instance, here's an article about what happened to the Mars Pathfinder 
mission:
http://research.microsoft.com/~mbj/Mars_Pathfinder/Mars_Pathfinder.html

Instead, we need better models of task concurrency. When possible, I use 
SharedQueues or similar synchronized structures to couple messages into and 
out of processes. Even this simple scheme (similar to "mailbox" structures in 
many RTOS designs) helps considerably.

I've found that I can generally design smaller embedded systems (say <64K of 
code and <4K of data) using simple state machines and an interrupt-driven 
executive, giving myself robust concurrency without semaphores or deadlocks.

-- 
Ned Konz
http://bike-nomad.com/squeak/



More information about the Squeak-dev mailing list