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

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. 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_lock, an msem or a semop) which serializes access to the state representing the event or mutex (as opposed to the state serialized by the mutex). When a thread waits for an event or a mutex it adds its SRA to a chain of SRA's waiting for the event or mutex (under the low level lock) and then waits on it's own SRA to be made dispatchable. When a post occurs the posting task takes the low level lock, removes the SRA from the chain of waiters, and makes the waiting task dispatchable. In the invention instead of the posting task making the waiting task dispatchable it acquires the low level lock for the associated mutex and conditionally adds the SRA to the chain of waiting SRA's for the mutex.

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...