Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism
•Télécharger en tant que PPT, PDF•
5 j'aime•3,978 vues
Presentation slides presented by Kasun Gajasinghe and Nisansa de Silva at Dept. of Computer Science & Engineering, University of Moratuwa. Slides are for the paper titled “Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism” by Thomas E. Anderson et.al.
![Scheduler Activations ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (13)
Similaire à Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism
Similaire à Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism (20)
Plus de Kasun Gajasinghe
Plus de Kasun Gajasinghe (7)
Dernier
Dernier (20)
Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism
- 1. SCHEDULER ACTIVATIONS Effective Kernel Support for the User-Level Management of Parallelism Kasun Gajasinghe Nisansa de Silva University of Moratuwa Based on the paper “Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism” by Thomas E. Anderson et.al.
- 20. Scheduler Activations - Programs Kernel Application 1 Address space
- 21. Scheduler Activations - Programs Kernel Application 1 Address space
- 22. Scheduler Activations - Upcalls Kernel Application 1 Address space
- 26. Scheduler Activations -Blocking Kernel Application 1 Address space
- 27. Scheduler Activations -Blocking Kernel Application 1 Address space
- 28. Scheduler Activations -Blocking Kernel Application 1 Address space
- 29. Scheduler Activations -Blocking Kernel Application 1 Address space
- 30. Scheduler Activations -Blocking Kernel Application 1 Address space
- 31. Scheduler Activations -Blocking Kernel Application 1 Address space P
- 32. Scheduler Activations -Multiprogramming Application 2 Address space Kernel Application 1 Address space
- 33. Scheduler Activations -Multiprogramming Application 2 Address space Kernel Application 1 Address space P
- 35. Scheduler Activations – Upcall Points
- 36. Scheduler Activations – Address space to Kernel
- 39. Scheduler Activations –Critical section Kernel Application 1 Address space P User level context switch!
- 53. THANK YOU!
Notes de l'éditeur
- This way, when a thread blocks on a user-level lock or condition variable, the thread scheduler can resume running without kernel intervention.
- Inform that 2 threads have stopped!
- an additional preemption may have to take place beyond the ones described above. For inst ante, on an I/0 completion, some processor could be running a thread with a lower priority than both the unblocked and the preempted thread. In that case, the user-level thread system can ask the kernel to interrupt the thread running on that processor and start a scheduler activation once the thread has been stopped. The user level can know to do this because it knows exactly which thread is running on each of its processors. the kernel’s interaction with the application is entirely in terms of scheduler activations. The application is free to build any other concurrency model on top of scheduler activations; the kernel’s behavior is exactly the same in every case. In particular, the kernel needs no knowledge of the data structures used to represent parallelism at the user level.
- More runnable threads than processors More processors than runnable threads If an applicatlon has notified the kernel that it has idle processors, and the kernel has not taken them away, then there must be no other work in the system, and the kernel need not be notified of changes in parallelism, up to the point where the application has more work than processors. These notifications are only hints: if the kernel gives an address space a processor that is no longer needed by the time it gets there, the address space simply returns the processor to the kernel with the updated information. Of course, the user-level thread system must serialize its notifications to the kernel, since ordering matters.
- This encourages address spaces to give up processors when they are needed elsewhere, since the priorities imply that it is likely that the processors will be returned when they are needed. This avoids the overhead of processor re-allocation when the work is created.
- because other threads continue to test an application-level spin-lock held by the preempted thread the preempted thread could be holding a lock on the user-level thread ready list; if so, deadlock would occur if the upcall attempted to place the preempted thread onto the ready list