3 ms·

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 Librar

by scott_s 14y ago

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 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 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.

pcwalton 14y ago
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.
- scott_s 14y ago
  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.
  - pcwalton 14y ago
    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.
    - scott_s 14y ago
      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.
zvrba 14y ago
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".
- scott_s 14y ago
  Note that the paper's author was one of the people who defined C++'s memory model for this very reason.

by scott_s 14y ago

pcwalton 14y ago

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.

scott_s 14y ago
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.
- pcwalton 14y ago
  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.
  - scott_s 14y ago
    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.

zvrba 14y ago

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".

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