• Summary
• Related Documents
  • Active Bibliography
  • Co-citation
• Version History

Abstract:

There has been a significant effort over the past decade in creating concurrency libraries for a number of sequential programming languages, particularly for object-oriented ones such as C++ [BLL88], Eiffel [KB93], and Smalltalk [YT86]. While the goal is laudable, this discussion shows that obtaining concurrency solely through libraries is, in general, unattainable in both shared-memory and distributed environments. An informal proof shows that while it is possible to build a concurrency library and applications that use it, no guarantee of correctness can be given without an unrealistic requirement being placed on the library designer and user, even when the library features are used correctly in a well formed concurrent program. This unrealistic requirement is the need to examine the executable instructions after every compilation of the library or application for incorrectly generated code. Furthermore, if incorrect code is found, it may not be possible to fix the problem directly. The library or application may have to be restructured, possibly significantly, to produce a working program. Such a requirement is clearly beyond that of any reasonable, practical technique, tool, or programmer. In other words, if a concurrency library imposes such an inspection and repair requirement, the library feature cannot be safely implemented. Moreover, such requirements violate the abstraction and encapsulation of the concurrency library itself because of the need to examine the generated code. The proof is based on the observation that any linguistic feature that affects code generation cannot be

Citations