On 30/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>
> ----- Original Message -----
> From: "Igor Stasenko" <siguctua at gmail.com>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Monday, October 29, 2007 5:59 PM
> Subject: Re: Concurrent Futures
>
>
> > On 30/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>
> >> I'd like to hear some description if the concept you have in mind, if you
> >> have the time.  What are you thinking about in this arena?
> >>
> > Well, in my concept i don't have a vats. A computing resources(native
> > threads) managed by VM and not visible at language level. So, a VM
> > parallelism is not a language parallelism.
> > You can't predict what native thread will serve concrete message for
> > concrete object, thus a load is distributed evenly.
> > This haves own limitations, but mostly when you interacting with
> > external libraries through primitives - some of the libraries can not
> > work (or can work differently) when you accessing them from different
> > native threads.
> > Some of the libraries designed with no multithreading in mind, so
> > using them concurrently may cause a system crash.
> > But i don't think that i'm alone with this problem. We need to find
> > some good ways how to control that all calls to some external library
> > must be invoked only from a single thread of execution, while for
> > other libraries its ok to call them from anywhere.
>
> How do you protect against simultaneous accesses to memory for writes/reads?
>
I have described this previously. The idea is simple. Since we have
limited set of write operations in object memory we could design a
system which prevents a primitive operations (such as primat: put:)
from running concurrently on the same object.
This means (like in your concept), that each object should have an
additional slot identifying a context where it used as receiver.
The only write operations which could modify object memory within any
method body is write to receiver memory (like setting ivar or indexed
var). Other operations (like pushing on stack) is safe, because we'll
have separate stack for each execution thread.
The message evaluation sequence then can be done as following:
- check receiver's assigned context
- if it's nil, then assign it to current and start executing method
- if its not nil, then schedule method execution to the thread, which
owns given context.

when performing a message send in method we deactivate the context,
which means that we can set assigned object's context to nil, and set
it again when activate context again. Or if we not, then all message
sends to given object will be scheduled to same native thread. I don't
know what is best - both approaches having own pros and cos.
Retaining a context can help us with making all calls to some external
library be invoked from single thread.

Either way we should ensure that there's a single active context at
some point of time in system running using same receiver. Also, we can
leave most primitives unmodified and be careless about concurrency in
these primitives, because by design, there can be only single
primitive running in system for particular object at any point of
time.

If you can see, such approach gives not much in solving concurrency
issues at language side. But that's where i think developers should
choose the way. We can provide all what they need
(semaphores/promises/futures e.t.c.) in libraries and provide some
additional primitives for controlling new aspects of VM.

> I agree that thread-safing the primitives is a key task.
>
> Cheers,
> Rob
>
>

-- 
Best regards,
Igor Stasenko AKA sig.