Preparing your result...
Loading...
Press Esc to dismiss this message

Method to Ensure No Thread of a Process is Executing in Userspace (02-Feb-2010)

Thumbnail
IP.com Prior Art Database Disclosure (Source: IPCOM)
Disclosure Number IPCOM000192773D dated 02-Feb-2010
Originally published in Prior Art Database
Disclosed by: IBM
Country: Undisclosed
Disclosure File: 2 pages / 68.2 KB / English (United States)

A method and system is disclosed for controlling and debugging multi-threaded processes. The method ensures that all threads of a process are not running userspace.

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

Page 1 of 2

Method to Ensure No Thread of a Process is Executing in Userspace

A method is provided to ensure no threads of a process are executing userspace. The method involves identifying a data structure which is common to all threads of the process. For example, struct signal

embedded in the data structure. Additional information is also embedded along with the field. The additional information may include information pertaining to a thread which requested the SQ.

Further, a routine in the return-to-userspace path in the kernel is identified. Subsequently, it is checked if a thread returning to userspace has a SQ flag set. In case, the SQ flag is set, the

processor is yielded such that another thread can run. Thereafter, the method waits for a

quiescent time interval (time that is at least equal to the time by which a scheduler would have

run at least once). After the quiescent time interval, it is established that no threads of the

process are running userspace based on the following observations:

If any thread was running in userspace, after its timeslice expiry, it would have come to the kernel and the scheduler will look at the thread state and determine that the thread is not ready to run. Hence the thread is now stopped. This is true even for SCHED

threads.

If any thread wasn't running on any processor, it would not be scheduled since its state indicates that it is not ready to run.

A thread blocked in the kernel is fair game; it isn't executing userspace. In any case, this thread will be stopped at the kernel-user boundary and would not go back to userspace. Threads that entered the kernel during this interval are also fair game as they are not running userspace code.

Once the required activity is complete, another request to reset the SQ changes the task state of each of the threads of the process to indicate that the task is no longer blocked on a SQ request.

Consider an exemplary scenario whe...

(Source: IPCOM)
First page image
(Source: IPCOM)