Squeak and native threads

On Sat, Jan 06, 2007 at 10:07:17AM +0000, J J wrote:
> Hello all,
>
> Is anyone doing anything (or know of someone who is) with native threading
> in squeak?  As computers begin to rely more and more on a multi-core
> strategy for speed up it is going to become more and more important to
> support native threading.

Why do you say that? Is it mostly in order to harness
multi-processors?

Perhaps what is needed is not native threads, but a way to
replicate computation. Sharing memory is not very critical in
this case, IMHO, as multi-threaded algorithms and servers
communicate through very narrow channels (all they share is a
couple of queues and variables). Thus sharing memory may not be
as important as we think. Of course, there are always
exceptions, like automatic parallelization:
http://ogun.stanford.edu/~kunle/publications/hydra_PACT98.pdf

I think an easy way to get multiprocessor functionality *right
now* is to launch one Squeak processes per processor, and have
croquet replicate some or all of the objects in the squeak
image. I think this would provide good multi-processor
functionality for squeak, and it would work both for inter and
intra-machine multi-processing. Shared memory would merely be an
optimization to make intra-machine communication faster, and
could be made semi-transparent. All that is needed to get this
working is a mechanism to have some threads launched on a remote
squeak process. So, I think croquet provides a framework that can
be used to harness multiple processors *right now*.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

On Wed, 10 Jan 2007 11:27:50 -0700, Matthew Fulmer <[hidden email]>
wrote:

> I think an easy way to get multiprocessor functionality *right
> now* is to launch one Squeak processes per processor, and have
> croquet replicate some or all of the objects in the squeak
> image.

That's exactly what I plan on doing, although I probably won't use Croquet.
The two images are going to be doing fundamentally different things, and
one will be feeding the other with the "answers". Specifically, the vision
processing image will be doing object recognition and color blob tracking,
and passing very little data over to the other image, running the "brain"
of the system.

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog

Because CPU's now double in speed by simply doubling up on cores.  If your
application (or language) can only run in one thread then your speed halves
(compared to those who don't have this limitation) every time a new core is
released.

_________________________________________________________________
Find sales, coupons, and free shipping, all in one place!  MSN Shopping
Sales & Deals
http://shopping.msn.com/content/shp/?ctid=198,ptnrid=176,ptnrdata=200639

Zulq Alam wrote on Date: Sun, 07 Jan 2007 18:14:28 +0000
> I found http://wiki.squeak.org/squeak/537 very interesting on this whole
> subject. I was especially interested in the work on Merlin/TinySelf
> where message sending is (as I understand it) asynchronous. I wonder
> what would be required to spike this in Squeak even if just simulated?

The "wait by necessity" model  in tinySelf 1 was borrowed from a
parallel version of Eiffel. It is a middle ground between true
asynchronous messages and synchronous ones. I think that the model in E
in several other systems are the same. Eiffel made a distinction between
active and passive objects while I tried to have active objects
exclusively in tinySelf 1 (one thread per object). A consequence of this
was that it was easy to have deadlocks - any direct or indirect
recursion would do and this is very common in Smalltalk code. My
solution was to detect deadlocks and automatically break them with the
idea that any bugs that resulted from this would be exactly the same
bugs you would have in a sequential execution of the same code so it
wouldn't shock the programmer too much.

One thing that the Eiffel system did and I didn't was to lock all of the
message's arguments in addition to the receiver. This, combined with the
passive objects idea, gave their system a more reasonable view of what
an object's state is and how to make it change atomically. What I mean
is that if you send a message to A and it in turn sends a message to B
which changes the state of B you have to consider that the original
message changed (indirectly) the state of A. TinySelf 1's system had too
narrow a view of what an object's state was and didn't handle this.

My current system is like Tweak Islands (if I understood correctly) in
that objects are divided into groups and there is one thread per group.
It is soft of like the Eiffel system but instead of one special active
root object pointing to a bunch of passive subobjects you have all
objects in the group of the same kind. Messages within a group are
synchronous while between objects of different groups use the "futures"
scheme.

-- Jecel

Maybe, but whatever the implementation there need to be comprehensible
APIs or language constructs.

Matthew Fulmer wrote:
> Perhaps what is needed is not native threads, but a way to
> replicate computation.