On 01/11/2007, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
> > Or as i proposed in earlier posts, the other way could be to schedule
> > all primitive calls, which currently don't support multi-threading to
> > single 'main' thread.
>
> I thought about this a little more today and decided this is indeed the
> better way to go. It preserves all the semantics that currently exist in
> Squeak with regards of running in the UI thread etc. It is also trivial
> to implement since we'll need some sort of thread identifier per VM
> instance so the test can be done without any additional synchronization
> overhead.
>
> So the (updated) steps to the multi-threaded VM would then be:
>
> 1) Objectify the Interpreter by making the code generator generate the
> appropriate code.
>
> 2) Implement the "failure mode" for calling primitives from non-primary
> threads and possibly implement the first few plugins that are
> multi-threaded (files, sockets, ffi come to mind).
>

Writing a generic threading framework comes in mind.
A brief description:
- each object in system should have a way how to get it's assigned
thread id (and how assign it , of course).
- if we see, that object having assigned thread, that means, that this
object is 'captured' by given thread for processing, and we need to
schedule new messages to that thread.

Early i proposed this approach only for smalltalk objects and their
active contexts, but this concept can be easily expanded to virtually
any objects in system (Interpreter/GC/primitives).

For instance, a concurrent GC mark phase can be implemented by following:
- we have a single thread which dedicated for marking
- for each object we want to mark we should send a 'mark' message to it.
If given object is not 'busy' (not having a thread id set) we simply
set it and begin marking its references.
if its already set, then we schedule a mark message to the thread
where it currently assigned and can continue with own queue (mark
other objects).
You can see that with this concept we can virtually mix an interpreter
'sends' with VM low-level 'sends'.
In that way i even thinking what if not having a dedicated thread for
marking, just start it in some single thread (when we have a GC
criteria met) and let it go until it converges.
Eventually if we push further, we can come up with parallel marking,
then we don't need to have a 'sync' points and never need a GIL.

> And then, either:
>
> 3a) For message passing concurrency: Implement a "load image" primitive
> which allows loading and running another image in parallel.
>
> 3b) For shared state concurrency: Implement allocation and GC sync points.
>
> Any interest in actually doing this? I think I might even be able to
> find some funding for a project like this if someone has a bit of spare
> time to work on it. If you are interested, let me know off-list.
>
I'm on board :)

> Cheers,
>    - Andreas
>
>


-- 
Best regards,
Igor Stasenko AKA sig.