Browse Prior Art Database

WaitAndLock service to avoid false dispatching

IP.com Disclosure Number: IPCOM000015393D
Original Publication Date: 2002-May-16
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 40K

Publishing Venue

IBM

Abstract

In a multiprocess environment it is common to wait for an event to occur and common to need to serialize access to resources.

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

Page 1 of 2

WaitAndLock service to avoid false dispatching

In a multiprocess environment it is common to wait for an event to occur and common to need to serialize access to resources.

     A problem can exist where a task waits for an event to occur, for example a message to arrive, and then locks a resource associated with the event, for example a message queue, in that typically the resource associated with the event is locked by the task that posts the event. In many environments when the event is posted the task waiting on the event will be immediately dispatched and will request access to the serialized resource before the task posting the event has relinquished serialization of the resource. This results in unnecessary dispatching as the 'waiting' task must immediately be suspended to wait for the posting task to release the resource. By implementing a combined WaitAndLock event then when the post occurs the posting task can check if the lock is immediately available and if so can assign the lock to the waiting task and make the waiting task dispatchable. If the lock is not immediately dispatchable then the waiting task is moved from waiting on the event to waiting for the lock by the posting task.

     The invention eliminates 'false dispatching'. In a messaging system such as IBM's MQSeries* (on unix) each thread of control that can wait for an event or a mutex has an associated SuspendResumeArea (SRA) including an operating system primitive which supports some kind of suspend/resume operation (e.g. a pthread condition variable or a SystemV semaphore). Each event or mutex is represented by a control block including a low level lock (e.g. a pthread_mutex_l...