On Mon, Jul 7, 2008 at 8:08 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Peter William Lount wrote:
>
>>
>> Why prevent others from having their needed multiple native threads?
>>
>>
> It's not about preventing anything. If you have a proposal for how to do
> multiple threads per image I will most definitely listen, and if it is a
> reasonable proposal (i.e., one that can be implemented with bounded
> resources) I will even try to find funding for it. However, until such a
> time that there is a proposal I will drop this pointless discussion since,
> simply put, there is nothing to discuss here. The only available path at
> this point is by using one native thread per image and consequently that's
> what's going to happen.
>


If I were working on a concurrent VM, I'd just barge ahead and parallelise
the Squeak VM:

* I'd refactor the VM so that multiple copies of the interpreter state could
be held in the heap. I'd design it so that each pthread would run one
instance of the standard Squeak interpreter, and so that each interpreter
runs multiple green theads as it does now. This makes forking a very cheap
operation and allows for having as many green threads as would fit in
memory.
* I'd then see what needs fixing in the VM / plug-ins / image to make it
work. I'd probably start with the simple approach: an evil but simple global
VM lock for memory writing operations, and no changes to GC. Later, we can
revisit this to make it scale better.
* I'd then spend the next decade finding and fixing concurrency bugs.

What I'm actually going to do is:

* Modify the Squeak schedular to simulate concurrency better and bring up
lots of concurrency bugs in the image.
* Spend a decade fixing concurrency bugs in the image.
* Write enough concurrent code to make it worth having a concurrent VM.
* Sell that code, make a lot of money.
* Buy the rights to Gemstone or some other high-performance, concurrent VM.
* Port my code to that instead.
* Make a lot more money.

Gulik.


-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080708/00c65ac9/attachment.htm