Changes between Version 11 and Version 12 of scheduler

Timestamp:

Sep 23, 2018, 1:10:41 PM (6 years ago)

Author:

alain

Comment:

--

scheduler

@@ -15 +15 @@
 ALMOS-MKH defines two types of threads: 
  * USER threads are POSIX compliant threads, defined in a given user process. A main thread is always created for an user process. Other threads are created by the pthread_create() syscall.
- * KERNEL threads implement kernels services: RPC threads execute the Remote Procedure Calls; DEV threads implement IO channels operations, and IDLE thread is the default (low-power) thread. 
+ * KERNEL threads implement kernels services: RPC threads execute the Remote Procedure Calls; DEV threads implement IO channels operations, and the IDLE thread is the default (low-power) thread. 
 
 From the scheduler point of view, any thread (KERNEL or USER) can be in three states:
@@ -41 +41 @@
 Finally ALMOS_MKH implements the following scheduling priority :   RPC > DEV > USER > IDLE 
 
-== D) Delayed Context Switches ==
+== D) Context Switches ==
+
+As a general rule, a thread can deschedule when it is holding an high level kernel lock (queuelock or rwlock), but cannot deschedule when it is holding a kernel busy-waiting lock. 
 
 Context switches can have two causes:
-The RUNNING thread can explicitly ask to be descheduled, when blocked on a shared resource. Before descheduling, the thread should release all kernel locks.
-But the scheduling policy being preemptive,  the RUNNING thread can hold one (or several) kernel lock(s) when receiving a TICK interrupt. 
+The RUNNING thread can explicitly ask to be descheduled, when blocked on a shared resource. Before descheduling, the thread should release all taken kernel busy locks. But the scheduling policy being preemptive,  the RUNNING thread can hold one (or several) kernel lock(s) when receiving a TICK interrupt. Therefore, the 
+busylock_acquire() function disables IRQs before it takes the lock, and the busylock_release() function restore IRQs only after it releases the lock.
 
-In this situation, ALMOS-MKH implements the following delayed context switch mechanism:
- 1. The RUNNING thread holding locks continues execution, but the THREAD_FLAG_SCHED is set in the running thread descriptor.
- 2. All kernel functions used to release kernel locks check this THREAD_FLAG_SCHED. When this flag is set, and the last lock is released by the calling thread, the sched_yield() is immediately executed.
-
-More generally, ALMOS-MKH supports descheduling of an USER thread that is currently in kernel mode - as a result of a syscall. In other words, syscalls can be interrupted by interrupts signaling the completion of an I/O operations, or by the TICK interrupt, requiring a context switch. 
+On the other hand, ALMOS-MKH supports descheduling of an USER thread that is currently in kernel mode - as a result of a syscall. In other words, some syscalls (not all) can be interrupted by interrupts signaling the completion of an I/O operations, or by the TICK interrupt, requiring a context switch. 
 
 == E) Floating Point Unit ==