Re: Gwydion & threads

[Eric Gouriou <address@hidden>]

Andreas Bogk wrote:
> Andreas Bogk <andreas@andreas.org> writes:
> > IIRC, assignments don't need to be atomic.
> 
> Ok, at least the Fun-O documentation says otherwise, and I can't find
> the original threads proposal anymore.
> 
> The good news is that assignment *is* atomic, even in the presence of
> a separate type pointer.  This is because data and type are stored
> together in a descriptor_t structure on the heap, and assignments to
> variables and slots just assign the descriptor_t pointer.
> 
> Slot assignment looks like this:
> 
> L_temp_2.heapptr = tZliteral.heapptr;
> L_temp_2.dataword.l = 23;
> SLOT(L_bar.heapptr, descriptor_t, 4) = L_temp_2;
> 
> and variable assignment like this:
> 
> L_temp_3.heapptr = tZliteral.heapptr;
> L_temp_3.dataword.l = 42;
> tZtZbaz = L_temp_3;

 The bad news is that this doesn't make any of those assignments
atomic.

 With a 32 bits data model, the descriptor_t is 64 bits,
and the assignment can only be atomic if the write to memory
is a 64 bits atomic write.

 With a 64 bits data model, the descriptor_t is 128 bits,
and you need a 128 bits atomic write to guarantee atomicity.

 I do not know which architectures will offer you an atomic
64bits write for ILP32 executables (IA64 can thanks to ILP32
being only a software convention while the processor is always
running in 64bits mode). But there is no guarantee that
the descriptor_t assignment will even use a single 64bit write.
(You could complain about a stupid compiler, but there is nothing
 in the C semantics that would guarantee it).

 Moreover you do not want to use atomic writes for each
descriptor_t access, as atomic writes typically have
memory barriers semantics that will kill the memory system
performance.

 So the descriptor_t approach will never give you good & thread-safe
performance on all architectures. A subset of architectures & data models
may give you performance & thread-safety, if you can ensure that
the compiler is going along with your wishes.

 Eric

-- 
Eric Gouriou                             egouriou@cup.hp.com