help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Re: [feature] Add SMP support to VM


From: Paolo Bonzini
Subject: [Help-smalltalk] Re: [feature] Add SMP support to VM
Date: Wed, 10 Oct 2007 04:46:20 -0700

Issue status update for http://smalltalk.gnu.org/project/issue/98 Post a follow up: http://smalltalk.gnu.org/project/comments/add/98

Project:      GNU Smalltalk
Version:      <none>
Component:    VM
Category:     feature requests
Priority:     normal
Assigned to:  Unassigned
Reported by:  sblinn
Updated by:   bonzinip
-Status:       active
+Status:       postponed

It's not "impossible", and with OpenMP support in GCC it can actually be
done, I think.  Not anytime soon, though. :-)

You could make the bytecode interpreter variables thread-local and put
the context switching into a critical section (i.e. only one kernel
thread could perform a green thread context switch, at a single time). GC and object allocation could also be put in a critical section. If
you can make sure that message sends can be executed concurrently, that
would be great.  I/O is not complicated, because it is already
asynchronous.

As I said, the easiest design would stop execution completely at GC
time.  But *within* GC you can do some tricks.  For new-space
collection, you could parallelize searching for roots in the grey
pages.  Mark'n'sweep is slow, and at least the mark phase could be
parallelized.

So, there are a few small opportunities here and there besides the "big
thing".

Replying to Robin, who "wants to control which [] fork results in a
real and which in a pseudo-thread", I say that I disagree strongly; I'd
want M:N threading (where N is the number of kernel threads and M is the
number of green threads) instead.

That's because Smalltalk processes /are already pre-emptive/, though by
default there is no time-sharing.  So, you need proper locking now too.

Suppose you have two processes P and Q modifying one variable.  A third
one, R, has lower priority than the first two and is waiting on a Delay.
While P process is modifying the variable, the Delay fires, and the
high-priority timing process is woken up.  This puts to sleep P and
sends it to the back of its ready-list.  You guessed right: when the
timing process goes back to sleep, Q is at the beginning of its
ready-list, and it can see the variable in a half-modified status.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]