Smalltalk › Squeak › Squeak - Dev

Concurrency classes...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Göran Krampe

Concurrency classes...

Hi folks!

I was googling for good concurrency classes for Java (cough) yesterday and
discovered Doug Lea's util.concurrent
(http://gee.cs.oswego.edu/dl/concurrency-interest/index.html) and the new
java.util.concurrent in Java 1.5 resulting from Doug's work
(http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/overview.html).

Now, this leads me to the question - how do we stack up in Squeak land?

AFAIK we have this:

1. Semaphore - the basic building block.
2. Monitor - the new "better Semaphore", but on a higher level.
3. SharedQueue - a simple queue, has been improved relatively lately.
4. SharedBufferStream - a different implementation of SharedQueue that is
more efficient and... well, a bit different. :) (my memory fails)
5. SharedBidirectionalStream - a combo of two SharedBufferStreams thus
mimicking a SocketStream "in image" since it has two independent channels
in both directions (like a SocketStream has). Quite fun to play with and
useful for multiplexing (multiple Processes sharing a SocketStream) etc.

(The two last classes are available in SharedStreams available on SM
(http://map.squeak.org/packagebyname/sharedstreams))

Surely we have lots more spread out in various places?

I know that most of the time we get by fine with Monitor and SharedQueue,
but some things that I feel are missing *and* would be useful is:

- something for executing "tasks"
- more concurrent Collections

regards, Göran

stephane ducasse

Re: Concurrency classes...

Hi goran

I think that you are right.
I'm just totally extremely bad with concurrent programming (I always
deadlock myself) to help but
yes there is something there to do.
Stef

On 26 janv. 07, at 09:42, Göran Krampe wrote:

> Hi folks!
>
> I was googling for good concurrency classes for Java (cough)
> yesterday and
> discovered Doug Lea's util.concurrent
> (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html) and
> the new
> java.util.concurrent in Java 1.5 resulting from Doug's work
> (http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/overview.html).
>
> Now, this leads me to the question - how do we stack up in Squeak
> land?
>
> AFAIK we have this:
>
> 1. Semaphore - the basic building block.
> 2. Monitor - the new "better Semaphore", but on a higher level.
> 3. SharedQueue - a simple queue, has been improved relatively lately.
> 4. SharedBufferStream - a different implementation of SharedQueue
> that is
> more efficient and... well, a bit different. :) (my memory fails)
> 5. SharedBidirectionalStream - a combo of two SharedBufferStreams thus
> mimicking a SocketStream "in image" since it has two independent
> channels
> in both directions (like a SocketStream has). Quite fun to play
> with and
> useful for multiplexing (multiple Processes sharing a SocketStream)
> etc.
>
> (The two last classes are available in SharedStreams available on SM
> (http://map.squeak.org/packagebyname/sharedstreams))
>
> Surely we have lots more spread out in various places?
>
> I know that most of the time we get by fine with Monitor and
> SharedQueue,
> but some things that I feel are missing *and* would be useful is:
>
> - something for executing "tasks"
> - more concurrent Collections
>
> regards, Göran
>
>
>

Philippe Marschall

Re: Concurrency classes...

In reply to this post by Göran Krampe

2007/1/26, Göran Krampe <[hidden email]>:

> Hi folks!
>
> I was googling for good concurrency classes for Java (cough) yesterday and
> discovered Doug Lea's util.concurrent
> (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html) and the new
> java.util.concurrent in Java 1.5 resulting from Doug's work
> (http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/overview.html).
>
> Now, this leads me to the question - how do we stack up in Squeak land?
>
> AFAIK we have this:
>
> 1. Semaphore - the basic building block.
> 2. Monitor - the new "better Semaphore", but on a higher level.
> 3. SharedQueue - a simple queue, has been improved relatively lately.
> 4. SharedBufferStream - a different implementation of SharedQueue that is
> more efficient and... well, a bit different. :) (my memory fails)
> 5. SharedBidirectionalStream - a combo of two SharedBufferStreams thus
> mimicking a SocketStream "in image" since it has two independent channels
> in both directions (like a SocketStream has). Quite fun to play with and
> useful for multiplexing (multiple Processes sharing a SocketStream) etc.
>
> (The two last classes are available in SharedStreams available on SM
> (http://map.squeak.org/packagebyname/sharedstreams))
>
> Surely we have lots more spread out in various places?
>
> I know that most of the time we get by fine with Monitor and SharedQueue,
> but some things that I feel are missing *and* would be useful is:
>
> - something for executing "tasks"
> - more concurrent Collections

We have also Mutex, which is a bit like Monitor, but simpler and with
only one Semaphore .....

Philippe

Michael van der Gulik

Re: Concurrency classes...

In reply to this post by Göran Krampe

Göran Krampe wrote:
> Hi folks!
>
> I was googling for good concurrency classes for Java (cough) yesterday and
> discovered Doug Lea's util.concurrent
> (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html) and the new
> java.util.concurrent in Java 1.5 resulting from Doug's work
> (http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/overview.html).
>
> Now, this leads me to the question - how do we stack up in Squeak land?

Well, in terms of intelligently using threads, not well.

Doing almost anything freezes all of Morphic. Even in a workspace, we
need to cause a global interupt (alt-.) to stop our tests.

The VM doesn't support using more than one OS (or hardware) thread.
Architectures like the XBox processor, Cell processor, Sun's T1 (32
threads), or even dual-core / hyperthreaded CPUs are wasted on Squeak.

Until the VM actually uses more than a single CPU, the only goal I can
see this achieving is to improve interactivity. There certainly won't be
much of a speed increase by using concurrent collections.

> AFAIK we have this:
>
> 1. Semaphore - the basic building block.
> 2. Monitor - the new "better Semaphore", but on a higher level.
> 3. SharedQueue - a simple queue, has been improved relatively lately.
> 4. SharedBufferStream - a different implementation of SharedQueue that is
> more efficient and... well, a bit different. :) (my memory fails)
> 5. SharedBidirectionalStream - a combo of two SharedBufferStreams thus
> mimicking a SocketStream "in image" since it has two independent channels
> in both directions (like a SocketStream has). Quite fun to play with and
> useful for multiplexing (multiple Processes sharing a SocketStream) etc.
>
> (The two last classes are available in SharedStreams available on SM
> (http://map.squeak.org/packagebyname/sharedstreams))
>
> Surely we have lots more spread out in various places?

I've implemented Futures in
http://www.squeaksource.com/DPON/MessageCapture-mvdg.9.mcz.

f := Future doing: [ some long computation ].
... do other stuff ...
f inspect. "Will block until the result for f is there."

But I really don't find Semaphores that hard to use and usually that's
all I use. I love the way you can just fork off a process almost as an
afterthought; writing concurrent applications in Smalltalk is quite simple!

Michael.