Hello, I am trying to figure out a schema to implement
multithreading on multiple cores for an language that
I'd like to design. First of all I came to the
conclusion that you cannot use native threads. Using
native threads means that your language implementation
can interrupt at any time, making a single asm-insn
the unit of atomicy. You need tons of synchronication
and need to think about raceconditions etc. which
explodes code complexity. The benefits of native
threads can better be achieved using custom programmed
threads, meaning: simple stack switching with a few
assembler insn. I found that the latest google-go
gcc branch of Ian Tailor is working on gcc support
for variable size stacks and split stacks: that means
you can increase the stack size dynamicaly while
executing. The only need for native threads would be
for blocking i/o, therefore I'd partition by langauge
implementation in 2 native threads, one handling the
I/o and the other implementing the threading in
custom fashion. Implementing threading myself means:
I can implement cooperative threading.
I can define blocks of atomicy without need of synchronisation.
I can derive a garbage collection schema where I can
ignore stack references.
Now I was thinking quite a long time on how to handle
multicore. Having handled mutithreading the easy way
i dont want to start over with synchronication on insn
level. Up till now didnt came up with a enlighting solution
therefore I'd like to know weather someone can give
me a idea...
The only thing that I came up would be
cross calls: A object belongs to a CPU. Every CPU
has a worker-thread running on every other CPU. If a CPU
tries to modify a object that doesnt belong to himself
if has to do a crosscall: If need to wake up the worker-thread
on the owner's cpu....
With only a few global objects this scheme might be applicable,
however it will shurely kill the system if you have
a lot of global objects...
Is there some other way to avoid the synchronization
overkill in multicode mode....
-- Greetings Konrad