I assume they depend on macros to do so? That changes the game. Hans Boehm has an excellent paper on this issue titled "Threads Cannot be Imlemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf That paper was published in PLDI (http://dl.acm.org/citation.cfm?id=1065042).

His arguments have much to do with what the compiler doesn't know, which could potentially be solved with macros.

You don't need macros to solve this problem. You can use unique types, STM, etc. to forbid the data sharing at the type level and ensure a coherent memory model.

The paper's position is that you can't implement threads, safely, as a library because the compiler is not aware of the concurrency. My point was that this reasoning may not hold if your language has full macros. Your suggestions will work great, but those are in the compiler, not as a library.

Well, the point is that concurrency primitives don't have to be built into the language to enable libraries to write safe concurrent abstractions. Rather, the type system features that enable it can exist in the compiler as general type system features unrelated to concurrency that just so happen to be able to ensure the safety of concurrent code if used properly.

I take your point, but I find it unlikely that anyone would defined the correct language semantics that would guarantee correct results under concurrency without designing for concurrency. Which is the point of Boehm's paper: your language (and its compiler) need to know about concurrency in order to get it right.

But these arguments are pretty much invalid today: C++11 introduces explicit support for concurrency, and the compiler MUST be aware of it, even though it may look (on the surface) as a "library".

Note that the paper's author was one of the people who defined C++'s memory model for this very reason.

Their (lack of) popularity suggests that the "at all" part might be a bit too absolute.

Not exactly prime choices for OO programmers, though