Squeak and threads

Joe Graham joe at aiobjects.com
Fri Dec 7 20:52:23 UTC 2001


>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..

However if the pattern is to use "message queueing" in Smalltalk (or maybe
just squeak?) then perhaps it is the better approach.  I guess you can fork,
create a new process or whatever all with the same mechanism so it sounds
very appealing.  What I wanted to know is if this is the general approach or
is this just a "workaround" for green threads?

-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Lex
Spoon
Sent: Friday, December 07, 2001 12:24 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Squeak and threads



"Joe Graham" <joe at aiobjects.com> wrote:
> Hello,
> I was curious how threads or process forking is implemented in Squeak.  Do
> consistent concurrency patterns exist that can be implemented amongst
> differnt flavours of Smalltalk?  If so, what are the implications as such?
>

In Squeak, a good way is to communicate with message queues, as
implemented in SharedQueue.  Otherwise, you can use Semaphores as
mutexes.

I've never run into a really *great* Smalltalk concurency approach that
deals with consistency, but would love to learn!

-Lex





More information about the Squeak-dev mailing list