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
|