"Joe Graham" <joe at aiobjects.com> wrote:
> >In Squeak, a good way is to communicate with message queues, as
> >implemented in SharedQueue.  Otherwise, you can use Semaphores as
> >mutexes.
> 
> okay, well i guess what i was looking for was an OO implementation around
> pthreads (or wotever) the native threading scheme is.  Ruby and Java (of
> course) have nice implementations of native multithreading APIs.  Utimately
> you only get signaling since threads are just a subprogram/process.  But it
> is nice to be able to have an API that deals with issues like "join",
> "rendevous", "wait", mutex, sem etc..

Ah.  Well, those aren't floating around in Squeak, though they can be
implemented on top of semaphores.  For rendevous (is that like a
barrier?) of k threads, signal the semaphore k times and then have
everyone do a "wait" at the semaphore.  For mutex, signal it once to
start with, and then go into a critical block by wait-ing and then
remember to signal on the way out (see the #critical: method).  Are join
and rendevous different?  Blah, it's been a while since I studied this
stuff.

It's really a bug-prone way to write concurrent programs.  If you signal
one time too few, then your barrier lets threads through a little too
quickly.  More commonly, if you forget to put a mutex around certain
chunks of code, then multiple threads can suddenly clobber each others'
work.  The situation is a lot like with manual memory management: for
simple systems, you can do it by hand and have a simple result.  For
complex systems, you can drive yourself crazy, and you are almost sure
to make mistakes that are very hard to track down.  Message passing, on
the other hand, isn't as bad: all the thread-relevant code is right near
the message-send and message-receive calls.


Another thing to consider is that in Squeak, more threads isn't going to
gain you performance.  Thus, the reason to use threads in Squeak would
be for design: sometimes you are writing a program that is inherently
parallel.

Now, the "inherent" parellism of a program seems to vary widely
depending on the observer, meaning in fact that it's not inherent after
all.  :)  I personally see these opportunities pretty rarely.  Perhaps,
though, this is from using Squeak so much -- the development environment
works much better for single-threaded programs.



-Lex