Re: [Caml-list] atomicity guarantees for threaded code

[skaller <skaller@users.sourceforge.net>]

On Sat, 2004-10-30 at 10:32, David Brown wrote:
> On Sat, Oct 30, 2004 at 09:54:37AM +1000, skaller wrote:
> 
> > > As long as the reference write is atomic, which it is going to be, I would
> > > suspect this is safe.  It probably would even be safe if multiple threads
> > > updated the reference, but you might just drop entries.
> > 
> > It isn't clear though. On x86 you can have 1 byte alignment
> > for an address. What happens if:
> 
> But, a reference in ocaml will always be in a block, which will always be
> aligned. 

On what boundary?

>  Even x86 will be atomic with a 32-bit transfer that is aligned.

But perhaps not a 64 bit one.

Part of my argument was that it is implementation
dependent. In particular, a page fault is only one
kind of interrupt. It is possible, for example,
to get another IRQ right in the middle of a transfer
from memory .. and interrupt the transfer. And that
IRQ could actually cause the page from which the
load was occuring to be swapped out .. meaning
it may not be necessary to be near a page boundary
to get a page fault... and thus the alignment
may not matter.

As I indicated some instructions on some processors
aren't atomic, particularly CISC machines.. it may be
that loading and storing isn't such an interruptible
instruction, but I'm not sure .. without checking
the x86 hardware manual. Certainly 48 bit loads
on a x386 can cause segmentation faults (I mean,
the whole thing is *designed* to do that) .. however
these don't normally apply to Unix like systems that
aren't capable of using segmented addressing
(in user space).

So I would guess you are right for all OS Ocaml supports.
Even so I'd be loath to rely on such a guess until
the Ocaml team asserted the guarrantee in the manual.

I wouldn't do it in C, because of the wide class
of platforms it applies to .. but Ocaml doesn't intend
to handle such a wide class.

If the guarrantee was made, it could simplify some
Ocaml programming significantly, and thus possibly
improve performance.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net