Browse Prior Art Database

Blocking/Non Blocking Access to Message Queues

IP.com Disclosure Number: IPCOM000117908D
Original Publication Date: 1996-Jul-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 73K

Publishing Venue

IBM

Related People

Jordan, RM: AUTHOR

Abstract

In managing message queues an operating system may permit an application to peek the contents of messages currently on the queue, and then delete an element from any position in the queue depending on its contents. When attempting to remove elements from an empty queue, it is desirable that the application be able to specify whether to block until an element becomes available, or to return immediately.

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

Blocking/Non Blocking Access to Message Queues

      In managing message queues an operating system may permit an
application to peek the contents of messages currently on the queue,
and then delete an element from any position in the queue depending
on its contents.  When attempting to remove elements from an empty
queue, it is desirable that the application be able to specify
whether to block until an element becomes available, or to return
immediately.

      In the described approach, each queue is represented by a
simple circular buffer, containing pointers to elements.  (The
elements themselves are maintained in a buffer pool managed by a
different part of the subsystem).  A head index and first_free index
are used to mark the section of circular buffer containing queued
elements.  A lock is associated with the queue to coordinate access
to the queue data structures from multiple processes.  This, in
itself, does not support blocking a process which tries to remove an
element from an empty queue.

      Blocking is a way in which the operating system puts a process
into a suspended state, in which it uses no CPU resource, but from
which it can be woken immediately the blocking condition is cleared.
By contrast, a busy-wait, or spin loop, is an inferior method whereby
a process continually retries the operation at intervals until it
succeeds.  Busy-waits consume CPU resource and may delay the process
from resuming due to the interval between successive retries.

      The solution for blocking requirement is to use a standard
UNIX (*) System V semaphore.  The semaphore always holds a value
corresponding to the number of elements which are available to be
read from the queue (except for short critical sections during which
the queue is locked).  Semaphore operations provided by the UNIX
operating system allow a process to check that the semaphore value is
positive, and if so, to decrement that value, the whole op...