Stephen White <spwhite / chariot.net.au> wrote:
>
>On Mon, 12 Feb 2001, Ben Tilly wrote:
>
> > Secondly synchronization requires locking.  If you have automatic 
>locking
> > going on then it either needs to be very coarse-grained (in which case 
>you
> > do not get good concurrency) or else it is fine-grained in which case 
>you
> > wind up with a lot of possibilities for deadlocks.
>
>You can only have deadlocks when there's resource contention. If the code 
>is
>written sequentially with the interpreter parallelising where it can, then
>it's just the same as a CPU executing instructions out of order.

I do not believe your scheme covers many possible
situations that could result in race conditions and
resource contention.

> > Instance variables are themselves threads.  What if my object assumes 
>that
> > my instance variables stay put while I am accessing them?
>
>I don't understand about instance variables being threads in their own
>right. An object would only have one thread so nothing has changed within
>the Object. The multi-threading is only between Objects.

I mean that instance variables are full objects in their
own right.  Also multiple objects can easily share the
same object internally.

> > Likewise many will (I certainly would) assume that if I make 3 method
> > calls in order that they will happen in order.
>
>They would, courtesy of single thread.

What I mean is that the assumption would be that this
is true whether or not you use the returns or not.
If you did not use the returns, you were going to
assume that there was parallelism and multi-thread this.

> > What if an instance variable of the object is busy?  In some sample code
> > that I sent you that could happen.
>
>The object thread has to supply the instance variable, so the ordering is
>still assured.

The instance variable may itself be an object that is
called elsewhere.  Also if I launch 3 method calls
(threads) with the same argument, all 3 will have the
same object being passed around and may have implicit
assumptions that nobody else is changing it.

> > Scenario.  A calls B, B yields to a block that calls A again.  Do we now
> > have deadlock?
>
>Good question. It could be handled by running two threads, which makes Ruby
>capable of handling streams, like sh scripting, or B's thread could be used
>to execute passed blocks like the way Ruby is now.

I don't feel confident that this can be solved in an
easy way.  Certainly multiplying threads strikes me as
digging us in deeper.

> > An idea I have heard very good things about in the Perl world which 
>might
> > fit very well indeed into Ruby is POE.
>
>Makes me cringe like every other multithreading scheme I've seen. :)

Makes me cringe less than your proposal.

> > For more of my thoughts on threading, see
> > http://206.170.14.76/index.pl?node_id=29620
> > http://www.bitmover.com/talks/cliq/slide01.html
>
>Your thoughts amd that slideshow are based on OS threading. I'm proposing
>Object threading, which would operate like processes running in a CORBA
>environment, just a lot easier and a lot faster.

I think there should be a division between what is
parallel and what is not, and that division should be
explicit.  In a Corba environment you have an OO
language, which has some objects that are remote calls,
and some that exist locally.  Objects shouldn't go remote
without warning AFAICS.

>Any out of order problems would be between processes. Any code or data
>accesses within each process would still be sequential, including instance
>variable accesses.

An instance variable is an object.  It is an object that
has no way of knowing whether it is the instance variable
of some other object.

How are you guaranteeing that instance variables don't
get called from elsewhere in the middle of a method
call?  (Ditto for the arguments passed into the call.)

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com