On 01/11/2007, Andreas Raab andreas.raab@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:
- Objectify the Interpreter by making the code generator generate the
appropriate code.
- 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