Re: Gwydion & threads

[Scott Ribe <address@hidden>]

>> 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?
> 
> I am not familiar with the internal affairs of d2c, but it just struck me
> that this problem could be solved by using a slightly different
> representation of Dylan objects.

The problem is deeper and more difficult than has been discussed. Our
discussions up to this point have assumed that an assignment, once made, is
visible to all threads. This is only true on a single-processor computer. On
a multiprocessor computer, a simple assignment in one thread will only
update the value in the cache of the current CPU, so a subsequent read from
another thread can get the old value from the cache of a different CPU.

Not just that, but cache is not necessarily written back to main memory in
order of modification, so a thread can read an arbitrarily strange mix of
up-to-date and stale values. Thus, ***ALL*** accesses to data that is shared
between threads must utilize some sort of thread-boundary synchronization
primitive--you can't get around the problems with ***ANY*** redesign of the
internal data structures, no matter how clever. The solution to this problem
must involve some special OS-level threading support. (Assuming of course
that direct control over the flushing of CPU cache is handled in the kernel
and not available to user-land processes!)

Now, if you remove the possibility of different threads running on different
CPUs, you can do it without any special OS support.


-- 
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 665-7007 voice