User level adaptive thread blocking

• US 6,223,204 B1
• Filed: 12/18/1996
• Issued: 04/24/2001
• Est. Priority Date: 12/18/1996
• Status: Expired due to Term

• Current Assignee: Oracle America, Inc. (Oracle Corporation)
• Original Assignee: Sun Microsystems Incorporated (Oracle Corporation)
• Inventors: Tucker, Andrew G.
• Primary Examiner(s): Banankhah, Majid A.
• Application Number:
  US08/767,353
• Time in Patent Office: 1,588 Days
• Field of Search: 395/733, 395/704, 395/551, 395/650, 395/477, 795/704, 713/200, 710/200, 710/5, 710/260, 709/103, 709/100, 709/101, 709/102, 709/104, 709/105, 709/107, 709/108
• US Class Current: 718/103
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Abstract

A computer apparatus with user and kernel level memory regions schedules multiple light weight processes to run on one or more data processors. A mutex protects data in memory and permits only one thread to access the data at a time. Data pertaining to the running status of each of the light weight processes is stored in one or more kernel data structures which are mapped to the user level. When a thread attempts to acquire a mutex held by another thread, then the kernel data structure is checked to determine the status of the light weight process and its associated thread. The thread attempting to acquire the mutex is caused to sleep or spin according to the current running or not running status of the light weight process. If the light weight process holding a mutex is running, then the thread attempting to acquire the mutex will spin. If the light weight process then holding a mutex is stopped, then the thread attempting to acquire the mutex will block or sleep until awakened.

Claims

1. A computer apparatus comprising:

a computer system, including a memory configured to include a user level memory region and an operating system level memory region;

a plurality of threads configured to operate in the user level memory region;

a plurality of light weight processes configured to operate in the operating system level memory region to run selected threads from the plurality of threads;

at least one data process for running the plurality of light weight processes;

a kernel data structure in the operating system level memory region that includes selected information on each thread that is presently running at least one light weight process;

a user data structure in the user level memory region, configured to receive information from the kernel data structure;

a mapping mechanism for mapping information from the kernel data structure into the user data structure;

a scheduling mechanism for associating at least one thread to run at least one of the plurality of light weight processes or a selected high priority process, based on the mapped information received by the user data structure, wherein the at least one thread is caused to enter a spin state when scheduled onto a light weight process that is running;

a light weight process status indicator that indicates status of at least one of the plurality of light weight processes, configured to be read by the scheduling mechanism for thread scheduling, wherein the at least one thread is caused to enter a sleep state when the at least one light weight process is in a non-running state;

wherein the scheduling mechanism is configured to distinguish between the selected high priority process and the at least one light weight process, to block the selected high priority process, to place the selected high priority process in a sleep state, and to allow the at least one light weight process to complete a process begun by the at least one light weight process.

2. The apparatus of claim 1, wherein said scheduling mechanism is configured to read said light weight process status indicator to determine a scheduling status for said at least one thread.

3. The apparatus of claim 1, wherein at least one of said user level memory region and said operating system level memory region implements a mutually exclusive lock on selected memory region code.

4. The apparatus of claim 1, wherein said light weight process status indicator indicates whether a selected thread is running.

5. The apparatus of claim 1, wherein said scheduling mechanism is configured to cause said at least one thread to block when said light weight process status indicator indicates that said at least one light weight process is not running.

6. A method for scheduling a thread onto a light weight process in a computer system, the method comprising:

storing run status of at least one light weight process in an operating system level memory and in a user level memory;

receiving a request for acquisition of a mutually exclusive (“

mutex”

) lock from a selected thread;

determining if the mutex lock is already acquired;

when the mutex lock is already acquired, identifying a light weight process that has acquired the mutex lock and determining run status of the identified light weight process;

when the identified light weight process is determined to be running, causing the selected thread to enter a spin state until completion of the process by the identified light weight process; and

when the identified light weight process is determined not to be running, causing the selected thread to enter a sleep state until the light weight process begins running.

7. The method of claim 6, further comprising:

when said mutex lock is not already acquired, allowing said selected thread to acquire said mutex lock.

8. The method of claim 6, further comprising:

distinguishing between said identified light weight process and at least one high priority process;

determining if the at least one high priority process is running; and

when the at least one high priority process is determined not to be running, causing the high priority process to enter a sleep state.

9. The method of claim 6, further comprising storing run status of said identified light weight process in a selected data structure of said operating system level memory that is not directly user accessible.

10. The method of claim 6, further comprising storing run status of said identified light weight process in a selected data structure of said operating system level memory that is user accessible.