Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Microkernel Synchronization Primitives

IP.com Disclosure Number: IPCOM000115513D
Original Publication Date: 1995-May-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 8 page(s) / 257K

Publishing Venue

IBM

Related People

Focazio, R: AUTHOR [+2]

Abstract

Disclosed is a kernel-supported primitive, or fundamental machine instruction, to support the need of the IBM* Microkernel for a synchronization primitive for multiple threads. The C threads synchronizers provided with the Mach base are too slow, are only accessible within a single task, are tied to the C threads implementation, and consume excess port resources.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 21% of the total text.

Microkernel Synchronization Primitives

      Disclosed is a kernel-supported primitive, or fundamental
machine instruction, to support the need of the IBM* Microkernel for
a synchronization primitive for multiple threads.  The C threads
synchronizers provided with the Mach base are too slow, are only
accessible within a single task, are tied to the C threads
implementation, and consume excess port resources.

      While traditional solutions to this problem call for the
creation of a new system object for synchronization, it is
alternately possible to take advantage of the fact that, for
everything needing to be synchronized in the microkernel system, an
association exists to a single system object handle (microkernel port
object).  The role of the object handles (ports) is to provide
controlled and synchronized access to a system-wide object by
multiple clients.  Currently, this is done solely through message
passing primitives on the port object.  However, since these
message-based primitives do not have all of the features desirable
for synchronization primitives, the semantics provided by the port
object is extended to include new (non-message-passing)
synchronization primitives.

      This technique is especially useful, since microkernel
resources are anonymous in nature.  Once a process is in possession
of a resource handle, it may be difficult to determine from where it
came or how to obtain its corresponding synchronizer object.  With
synchronization primitives, the resource handle (port) is all that is
needed.  Previously, only condition_wait() and condition_post() type
primitives have been added to the port objects, with more complex
operations being implemented using these primitives.  The advantage
adding more complex primitives is that these primitives can be added
at any time without requiring a complete restructure of the objects
needing to be managed.

      Object handles are made available to a task through two
distinct address spaces---the port space and the virtual memory
address space.  The port space assigns names to the ports, which are
then usable by these names.  Handles in the port space can be
accessed directly, and therefore can be used directly for
synchronization purposes.

      The virtual memory space of a task allows direct manipulation
of special system objects (known as memory objects), using the
virtual memory hardware of the system to provide rapid yet controlled
access.  Although it is possible to extract a system object handle
(port) from the microkernel for each range of virtual memory, and
then to issue synchronization primitives on that port, this process
is sometimes inefficient or awkward for the application to manage.
This problem is rectified in an implementation optimization, as
additional virtual memory synchronization primitives are  added to
convert a virtual memory address to a port/event pair internally, and
then to issue the port synchronization primitiv...