[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