ACM Home Page
Please provide us with feedback. Feedback
Threads cannot be implemented as a library
Full text PdfPdf (156 KB)
Source Conference on Programming Language Design and Implementation archive
Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation table of contents
Chicago, IL, USA
SESSION: Threads table of contents
Pages: 261 - 268  
Year of Publication: 2005
ISBN:1-59593-056-6
Also published in ...
Author
Hans-J. Boehm  HP Laboratories, Palo Alto, CA
Sponsors
SIGPLAN: ACM Special Interest Group on Programming Languages
ACM: Association for Computing Machinery
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 27,   Downloads (12 Months): 415,   Citation Count: 11
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

Tools and Actions: Review this Article  
Save this Article to a Binder    Display Formats: BibTex  EndNote ACM Ref   
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1065010.1065042
What is a DOI?

ABSTRACT

In many environments, multi-threaded code is written in a language that was originally designed without thread support (e.g. C), to which a library of threading primitives was subsequently added. There appears to be a general understanding that this is not the right approach. We provide specific arguments that a pure library approach, in which the compiler is designed independently of threading issues, cannot guarantee correctness of the resulting code.We first review why the approach almost works, and then examine some of the surprising behavior it may entail. We further illustrate that there are very simple cases in which a pure library-based approach seems incapable of expressing an efficient parallel algorithm.Our discussion takes place in the context of C with Pthreads, since it is commonly used, reasonably well specified, and does not attempt to ensure type-safety, which would entail even stronger constraints. The issues we raise are not specific to that context.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
A. Alexandrescu, H.-J. Boehm, K. Henney, B. Hutchings, D. Lea, and B. Pugh. Memory model for multithreaded C++: Issues. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1777.pdf.
 
2
A. Alexandrescu, H.-J. Boehm, K. Henney, D. Lea, and B. Pugh. Memory model for multithreaded C++. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1680.pdf.
3
4
5
 
6
H.-J. Boehm. A garbage collector for C and C++. http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
7
 
8
P. A. Buhr. Are safe concurrency libraries possible. Communications of the ACM, 38(2):117--120, February 1995.
9
10
 
11
Ericsson Computer Science Laboratory. Open source Erlang. http://www.erlang.org.
12
13
 
14
 
15
HP Technical Brief. Memory ordering optimization considerations. http://h21007.www2.hp.com/dspp/files/unprotected/ddk/Optmiztn.pdf.
 
16
IEEE and The Open Group. IEEE Standard 1003.1-2001. IEEE, 2001.
 
17
JSR 133 Expert Group. Jsr-133: Java memory model and thread specification. http://www.cs.umd.edu~pugh/java/memoryModel/jsr133.pdf, August 2004.
18
 
19
L. Lamport. How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Transactions on Computing, C-28(9):690--691, 1979.
 
20
D. Lea. Concurrency jsr-166 interest site. http://gee.cs.oswego.edu/dl/concurrency-interest.
 
21
D. Lea. The JSR-133 cookbook for compiler writers. http://gee.cs.oswego.edu/dl/jmm/cookbook.html.
22
23
24
 
25
B. Pugh. The "double-checked locking is broken" declaration. http://www.cs.umd.edu~pugh/java/memoryModel/DoubleCheckedLocking.html.
 
26
B. Pugh. The java memory model. http://www.cs.umd.edu/~pugh/java/memoryModel/.
 
27
W. Pugh. The java memory model is fatally flawed. Concurrency - Practice and Experience, 12(6):445--455, 2000.
28
29
30
31
32
 
33
A. Terekhov and D. Butenhof. The austin common standards revision group: Enhancement request 9 (austin/107): Clarification of "memory location". http://www.opengroup.org/austin/docs/austin_107.txt, May 2002.
 
34
The MPI Forum. The message passing interface (MPI) standard. http://www-unix.mcs.anl.gov/mpi/.
 
35
R. Treiber. Systems programming: Coping with parallelism. Technical Report RJ5118, IBM Almaden Research Center, 1986.
36

CITED BY  11