[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gwydion & threads
Jeffrey Siegal <jbs@quiotix.com> wrote:
>
> This is the key point. You *really* don't want a memory model where
> ordinary memory accesses are safe across threads if you want decent
> perforamnce on a multiprocessor system. Even if you know that memory
> writes are "atomic", how do you know that the compiler is writing a
> value to memory at all, when it could just store the value in a register
> for writing "later?"
What I'm worried about is about programs seeing impossible values and
dumping core. Suppose that object representation is (type-word,
value-or-pointer), where each of the two components are a word. So an
integer would be represented as (Integer-tag, <some-number>), and a
string would be (String-tag, <pointer>).
Now, take the following code:
define variable x = 1234567; // representation (Int, 1234567)
// in thread A
x := "foobar"; // x becomes (String-tag, pointer to "foobar")
// in thread B
frob(x);
Now, suppose that frob(x) is called when the assignment in thread A
has started but not completed, so that x has the value
(String-tag, 1234567).
Then frob could reach into random bits of memory and do unpredictable
things -- the language would be unsafe in the painful C sense, rather
than safe in the happy Lisp/Smalltalk sense.
When values are words, then even if the value of a variable is not
consistent across threads, they are alawys *values*, rather than
totally random bit-patterns. Now, I've not done much concurrent
programming, so I'd like to know if this a realistic concern?
Neel