Re: [Sablevm-developer] Threading support in SableVM

[Chris P. <chr...@ma...>]

Etienne Gagnon wrote:

> Chris Pickett wrote:

> 
>> However, I now have another test case (see attached), although I've only
>> seen this bug manifest itself on a multiprocessor. It might affect
>> uniprocessors in more complex scenarios.
> 
> 
> Multi-processor: part of the critical sablevm code for locking does NOT 
> take
> into account "cache issues".  For instance, "xxx.flag" is read and written
> assuming that any change is visible to other threads without 
> synchronization,
> which is probably NOT the case on a multiprocessor.

You're right, it's not the case ... see below.

> So, unless you can actually get your "bug" to manifest itself on a 
> uniprocessor,
> I wouldn't worry much about it.
> 
> Now, if you really want to get things running on a multi-processor, you 
> should
> start investigating cache issues. :-)  [WARNING: Not easy.  In fact, the 
> Java
> Memory Model is bronken on multi-processors...]


I started looking at the POSIX 1003.1c (pthreads) spec (it's
available online) and also at the comp.programming.threads FAQ (1 Mb
html file kills Mozilla on my machine, better to download) ... and
discovered a few interesting things:

1) The only way to ensure cache coherency in a portable manner is to use
the pthreads synchronization functions (e.g. lock and unlock).  So I
think that means there is no need for us to consider the Linux kernel
cache flush architecture, nor any processor-specific cache flush
instructions.

2) (a bit on "volatile" lifted verbatim):  You do NOT need volatile for
threaded programming. You do need it when you share data between "main
code" and signal handlers, or when sharing hardware registers with a
device. In certain restricted situations, it MIGHT help when sharing
unsynchronized data between threads (but don't count on it -- the
semantics of volatile" are too fuzzy). If you need volatile to share
data, protected by POSIX synchronization objects, between threads, then
your implementation is busted.

3) No unsynchronized operation on shared data, even if it takes only one
assembly instruction, is truly safe, with the exception of
"one-shot-flags", where data changes only in one direction and it only
changes once, and the actual changed-to value doesn't matter.  Although
it doesn't follow exactly the same semantics as a "one-shot-flag", the
preparation sequence REPLACE operation is safe by similar logic.

Cheers,
Chris