The real problem with C's volatile (well, one of them) is that volatile only affects the compiler; it doesn't normally make thecompiler do anything to affect the CPU's interaction with memory. Onmodern hardware, merely affecting the compiler is not enough; theCPU/memory interface has its own optimizations, which must be dealt withtoo for shared-state code to work right.

From the perspective of history this makes a lot of sense, becauseANSI C mostly predates CPU memory controllers

I have come to a grumpy realization recently:

Unsecured webmail systems are today's open SMTP relays, and it'shigh time that they got treated the same way.

The comparison is all the more striking because (once) major ISPsappear to have decided that they can run open webmail systemswithout consequences, much as people once shrugged off runningopen SMTP relays.

(I am particularly depressed by the move of places like rr.com,comcast.net, and adelphia.net into webmail systems that are

I've already linked to this in passing , but I'm going to rerun itas an explicit link. Threads Cannot be Implemented as a Library by HansBoehm makes the argument in its title:

We provide specific arguments that a pure library approach, in whichthe compiler is designed independently of threading issues, cannotguarantee correctness of the resulting code.

There is also a discussion of this paper at Lambda the Ultimate that may be interestingreading. On a quick skim of the LtU discussion thread, thisUsenet article

There are some things that Solaris is very good at; one of them isuser-level ABI compatibility (at least for basic programs). As anillustration of just how good it is, I only recently noticed that on ourSolaris 8 machines I am still routinely using some dynamically linkedprograms compiled in August of 1993 (which is probably when this groupstarted using Solaris machines).

I hadn't noticed before now because the programs hadn't really changedsince then (so I had no