Message passing between sequential processes: The reply primitive and the administrator concept

Gentleman, W. Morven

doi:10.1002/spe.4380110504

Cited by 120 publications

(31 citation statements)

References 21 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Without this ability, certain kinds of concurrency problems are quite difficult to implement, e.g. disk scheduling, and the amount of concurrency is inhibited as tasks are needlessly blocked [10].…”

Section: Introductionmentioning

confidence: 99%

μC++: Concurrency in the object‐oriented language C++

et al. 1992

View full text Add to dashboard Cite

SUMMARYWe present a design, including its motivation, for introducing concurrency into C++. The design work is based on a set of requirements and elementary execution properties that generate a corresponding set of programming language constructs needed to express concurrency. The new constructs continue to support object-oriented facilities like inheritance and code reuse. Features that allow flexibility in accepting and subsequently postponing servicing of requests are provided. Currently, a major portion of the design is implemented, supporting concurrent programs on shared-memory uniprocessor and multiprocessor computers.

show abstract

Section: Introductionmentioning

confidence: 99%

μC++: Concurrency in the object‐oriented language C++

et al. 1992

View full text Add to dashboard Cite

show abstract

“…Regardless of the reasons for using a modular multiserver design, one important caveat is that services can no longer make direct function calls. Instead, the kernel provides IPC services that allow sequential processes to synchronize and communicate [8]. However, since software cannot be trusted to be correct [1,5,12,26,28], this poses new challenges with respect to IPC threats caused by, for example, programming bugs, design and run-time faults, or misconfigured extensions, or malicious intent.…”

mentioning

confidence: 99%

Countering IPC Threats in Multiserver Operating Systems (A Fundamental Requirement for Dependability)

Herder¹,

Bos²,

Gras³

et al. 2008

2008 14th IEEE Pacific Rim International Symposium on Dependable Computing

View full text Add to dashboard Cite

Multiserver operating systems have great potential to improve dependability, but, paradoxically, are paired with inherently more complex interprocess communication (IPC). Several projects have attempted to run drivers and extensions in isolated protection domains, but a systematic way to deal with IPC threats posed by untrusted parties is not yet available in the literature. IPC is fundamental to the dependability of multiserver systems.In this paper, we present a classification of IPC threats in multiserver systems with unreliable and hostile senders and receivers, such as resource exhaustion, spoofing, and unauthorized access. We also introduce an extended asymmetric trust model, describing two new IPC vulnerabilities relating to caller blockage. Based on our classification of IPC threats we present the IPC defense mechanisms and architecture of MINIX 3.Keywords: Classification of IPC Threats, Dependable IPC Architecture, Multiserver Operating Systems IPC MUST BE DEPENDABLEMultiserver systems have great potential to improve operating system dependability. By running untrusted code in separate protection domains, bugs are better contained than in monolithic systems. In addition, the modular designs provide better abstractions and debugging and development support. Regardless of the reasons for using a modular multiserver design, one important caveat is that services can no longer make direct function calls. Instead, the kernel provides IPC services that allow sequential processes to synchronize and communicate [8]. However, since software cannot be trusted to be correct [1,5,12,26,28], this poses new challenges with respect to IPC threats caused by, for example, programming bugs, design and run-time faults, or misconfigured extensions, or malicious intent.To get an impression of what multiserver IPC entails, it is important to realize that seemingly simple system calls can cause intricate IPC patterns, whereas, applications can perform thousands of system calls per second. In MINIX 3, for example, a read or write call may lead to over 25 IPC messages between the application, virtual file system, file server, disk driver, and kernel. Measurements on Mac OS X and OpenDarwin, which use the Mach IPC mechanism, reported 102,885 and 29,895 messages from system boot until the shell is available, respectively [27]. We conducted the same measurement on MINIX 3 and obtained a similar number of 61,331 messages. Another experiment with ls -alR in /usr/src yielded 68,973 messages, whereas wget minix3.org initiated 4,862 messages. Background activity, such as the random driver gathering entropy, caused 476 messages/sec-with one IPC call taking in the order of a microsecond, this costs less than 0.05% of the CPU.The above examples constitute legitimate IPC, but without precautions, buggy senders and receivers (as shown in Fig.

show abstract

“…Harmony [14,15] is a multitasking multiprocessing realtime operating system. It has been ported to several hardware configurations.…”

Section: The Harmony Operating Systemmentioning

confidence: 99%

Realtime tracking in five degrees of freedom using two writs-mounted laser range finders

Venkatesan

Archibald

Proceedings., IEEE International Conference on Robotics and Automation

View full text Add to dashboard Cite

The results of experiments in realtime tracking of moving objects using wrist-mounted sensors are presented. Two laser range finders are mounted orthogonal to each other on the wrist of a six-degree-of-freedom PUMA robot. The objective is to have the robot end-effector maintain a constant position and orientation with respect to a flat object moving in three-dimensional space in the field of view of the range finders. Sensory feedback from the range finders is used to servo the robot such that its trajectory is similar to that of the moving object in five degrees of freedom. The algorithms for this application are implemented in C and run on four Motorola MC68020 processors with the Harmony** operating system. Tracking is done with maximum linear and angular speeds of the target object being 25 cm/s and 0.5 rads, respectively. The robot is capable of maintaining the required pose with respect to the object at these speeds with a small lag due mostly to data collection time. The acceleratiorddeceleration and the maximum speed of the robot trajectory are varied depending on the speed of the moving object being tracked to yield different tracking behaviours. A performance study of the tracking experiment is presented.

show abstract

Message passing between sequential processes: The reply primitive and the administrator concept

Cited by 120 publications

References 21 publications

μC++: Concurrency in the object‐oriented language C++

μC++: Concurrency in the object‐oriented language C++

Countering IPC Threats in Multiserver Operating Systems (A Fundamental Requirement for Dependability)

Realtime tracking in five degrees of freedom using two writs-mounted laser range finders

Contact Info

Product

Resources

About