Multy-core CPUs
Peter William Lount
peter at smalltalk.org
Sun Oct 21 04:53:05 UTC 2007
Hi Ralph,
Continued.
>> Parallel programming with no
>> shared memory, i.e. by having processes only communicate with shared
>> memory, is much easier to program.
>>
Another way to express what I'm saying is the following. You can run
multiple processes in either separate or one memory space. When running
in one memory space the following applies.
Sure you could have N threads - native or green - each running ONE
(Squeak) Smalltalk process running in one protected memory space as long
as NONE of these threads share ANY memory between them. That means no
objects being shared. That means each Smalltalk process is really it's
own image running independently with only one user level Smalltalk
process. Any communication between them with objects is serialized and
transmitted in some manner that - oh dear - avoids using shared memory
or a shared communications "buffer" between two or more threads. This is
done even though sending messages via shared memory buffers in one
protected memory space is very efficient or sending messages via a
shared memory space when more than one protected memory space is in use
is also very efficient.
It seems to me that as soon as you have more than one Smalltalk process
running in a Smalltalk image you will have concurrency control issues -
unless the forked off threads are trivial in nature. This fact is the
reason that I don't share your optimism about your solution - for if you
have more than one thread in accessing the same memory space -
regardless if they are in the same protected memory space or across
operating system processes - you've got the concurrency complexity and
program data consistency issues occurring. How do you avoid that?
Please educate me so that I fully understand your proposed solution.
Thank you.
All the best,
peter
More information about the Squeak-dev
mailing list
|