Date: Tue, 30 Oct 2007 11:00:48 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Ivan Voras <ivoras@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: C++ in the kernel Message-ID: <60B5543F-CB5D-4E1C-8F36-5BAE1818D1CE@mac.com> In-Reply-To: <33676.1193689342@critter.freebsd.dk> References: <33676.1193689342@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?60B5543F-CB5D-4E1C-8F36-5BAE1818D1CE>