Henry Spencer sent me a reply to my previous entry on volatile that corrects some of my (mis)information, and I amputting it here with his permission:

I fear you've miscalled this one. ANSI C pre-dates aggressive memorycontrollers in consumer CPUs , but it had extensive participation bypeople in the supercomputer world as well, and such things were commonthere long ago.

The key issue you've missed is that ANSI C doesn't really acknowledge theexistence of a "compiler".

It's only recently that I've realized how jumpy about certain thingsmy NPTL (the 'native Posix thread library' for Linux) experience stillmakes me.

NPTL was the new, improved Linux threading library, supplantingthe old and less efficient 'pthreads' library. To get its goodperformance it needed some kernel support, kernel support thatwas only added in the Linux 2.5 development kernels (and thenin Linux 2.6 when 2.5 turned into 2.6).

However,

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