C++ in the kernel

[Marcel Moolenaar]

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 at mac.com