Anyway, no need for native threads to show how broken it can be...
It's not only a matter of operation atomicity.
Classes and methods must stay in sync, or bad things will happen.
Just try this with current green thread model:

Object subclass: #AAA instanceVariableNames: 'a b c'.
(Smalltalk at: #AAA) compile: 'test1
	(Delay forSeconds: 2) wait.
	c := 0' classified: 'test'.
[(Smalltalk at: #AAA) new test1] forkAt: Processor userInterruptPriority.
Object subclass: #AAA instanceVariableNames: 'c'.

Sooner or later, your VM should crash because ClassBuilder did not
take care to analyze concurrent Process Context stack... Or because VM
did not take care to lock receiver of some Context...

Fortunately, a base image uses very few processes but for some hard to
modify/debug low level operations the average user should better not
touch (event fetching, finalization, ...).

Nicolas

2009/4/30 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 2009/4/30 Michael van der Gulik <mikevdg at gmail.com>:
>> On 4/29/09, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>>> As for moving to multi-cores.. yes, as Gulik suggests, its like adding
>>> a new dimension:
>>>  - local scheduler for each core
>>>  - single global scheduler for freezing everything
>>>
>>> This, of course, if we could afford running same object memory over
>>> multiple cores. Handling interpreter/object memory state(s) with
>>> multiple cores is not trivial thing.
>>
>> Implementing it isn't hard. It's fixing all the bugs we'll find that's
>> hard. There'll be bugs in the image and in the VM, and it'll be a good
>> 30 years before we've found them all.
>>
>> *Most* parts of the VM will continue working fine. The parts that will
>> break... er... some of the parts that will break are:
>>
>> * garbage collection.
>> * allocating memory for new objects.
>> * primitives and devices.
>> * pointer swapping *might* need to be atomic (become:, becomeForward:).
>> * Semaphore signalling.
>> * (more things???)
>>
>
> I love the *might*
>
> What happens for example if you change a class definition... Say add
> or remove an instance slot.
> What would happen if the becomeForward on the array of instances and
> subinstances and method dictionaries were not atomic?
>
> Don't forget Smalltalk environment rely on such in vivo chirurgical operations.
> You should better stop running while you or another thread is
> replacing your own leg.
>
> Of course, there is not a single solution. We could invent a world
> where there is a compile phase and an execution phase...
>
> Nicolas
>