Robert C. B. Cooper

dblp:85/1559 · DBLP profile ↗
← Back
2ranked-venue papers
2as first author
0since 2021 · last 1999
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Security and privacy · 1 · 1 first-authorSoftware engineering, systems software and programming languages · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Concurrent programming · 60% Operating systems · 20% Programming languages and type systems · 20%

Topics — the 4 heaviest of 5, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Programming languages and type systems
abstract data types
0.011988
Preserving Abstraction in Concurrent Programming · IEEE Trans. Software Eng. 1988
Operating systems › resource management
deadlock avoidance
0.011988
Preserving Abstraction in Concurrent Programming · IEEE Trans. Software Eng. 1988
Concurrent programming › synchronization
monitors
0.011988
Preserving Abstraction in Concurrent Programming · IEEE Trans. Software Eng. 1988
Concurrent programming
synchronization
0.011988
Preserving Abstraction in Concurrent Programming · IEEE Trans. Software Eng. 1988

Methods — techniques the papers use, named apart from their topics

fine-grain locking · 0.0
YearPublicationVenuePosition
1999 Reliability of Future Telephone Networks
abstract
The telecommunications industry is rapidly deploying packet based data networks to augment or replace the existing circuit switched telephone network. This trend is driven by the dramatic growth in data and new types of media, leaving voice traffic consuming a small fraction of the total bandwidth.
Robert C. B. Cooper
SRDS1
1988 Preserving Abstraction in Concurrent Programming
abstract
Recent programming languages have attempted to provide support for concurrency and for modular programming based on abstract interfaces. Building on experience of adding monitors to CLU, a language oriented towards data abstraction, it is explained how these two goals conflict. In particular, the clash between conventional views on interface abstraction and the programming style required for avoiding monitor deadlock is discussed. It is argued that the best compromise between these goals is a combination of a fine-grain locking mechanism together with a method for explicitly defining concurrency properties for selected interfaces.>
Robert C. B. Cooper, K. G. Hamilton
IEEE Trans. Software Eng.1