On Oct 29, 2007, at 1:22 PM, Poul-Henning Kamp wrote:

> For instance, the entire "dual-address space" dictomy og system
> calls/copy{in,out} and the very concept of interrupts are very
> tricky to sensibly express in anything but C.


Serialization and multi-threading is another thing that cannot be
expressed in or isn't part of the language and as such a possible
cause for bugs. Those bugs are the result of invalid compiler
optimizations -- that is valid in the normal case, but invalid
related to locking or multi-threading.

Think for example about common sub-expression elimination (CSE) in
the context of:

lock()
a1 = x
...
x = a2
unlock()

...

lock()
b1 = x
...
x = b2
unlock()

If the compiler knows that lock() and unlock() cannot change
the value of x (by virtue of making lock() and unlock() pure
and side-effect free) then it may end up generating:


c = x

...

lock()
a1 = c
...
x = a2
unlock()

...

lock()
b1 = c
...
x = b2
unlock()

Now we have a reference to x that's not protected by
the lock and doesn't take multi-threading into account
(i.e. the second load cannot be eliminated because x
may have changed) and may result in runtime failures.

Making x volatile is just a pessimization because that
prevents valid CSE operations.

See also:
Hans Boehm, Reordering constraints for pthread-style locks,
ACM SIGPLAN, 2007
http://portal.acm.org/citation.cfm?id=1229470

--
Marcel Moolenaar
xcllnt@mac.com


_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"