| commit | 89bf42b05f064ec66d142af0e8c92e45b26c821f | |
| author | Neale Ferguson <neale@sinenomine.net> | |
| Mon, 20 Jun 2016 14:26:51 +0000 (20 10:26 -0400) | ||
| committer | Aleksey Kliger (λgeek) <akliger@gmail.com> | |
| Mon, 20 Jun 2016 14:26:51 +0000 (20 10:26 -0400) | ||
| tree | 0830e9407fce743a30ee037782a47c497b2a8f03 | treesnapshot (tar.gz zip) |
| parent | 081781dd93463f369922475b3c19dd1170579240 | commitdiff |
Use thread priority at thread start time (#3123)
* An enhancement to the thread priority work added earlier. This will support starting a thread with a specified priority. Currently, the thread will start with the priority of the creator. The semantics of threads allow you to specify the priority of a thread before it has started. Therefore, we take note of this value at thread creation time.
* Missed committing this file the first time
* Correct typo
* Fix creation_flags reference
* MonoThreadParm really should not be in objects-internal
* Place priority in MonoInternalThread where it can be accessed by GetThreadPriority(). This enablses the priority to be set/retrieved before the thread is started. It also ensures that new threads default to a priority of THREAD_PRIORITY_NORMAL rather than inheriting the parent thread's priority.
* Revert changes to MonoInternalThread/Thread.cs. Properly use the handle for thread lookup. Initialize priority at thread creation time. Use stored value of priority if thread has not been started.
* Add code to handle retrieving the thread priority from a started thread that had been set before thread had started. This is necessary as before the thread is started the priority value can be manipulated. This value is stored in the MonoThread structure. Before the thread is started the value can be interrogated so we return this value rather than invoking the GetThreadPriority() API. When a thread is started this value is used to set the threads priority (if scheduling policy is SCHED_FIFO or SCHED_RR). For POSIX threads, after the thread is started we now keep the priority in the _Wapi_thread structure which is located via the thread handle. This structure doesn't exist until after the thread is started so we can't store the value there but after we can cache the priority value there and return it for non-SCHED_[RR|FIFO] threads. This way the expected value will always be set and returned by ThreadPriority property (currently for these threads it will simply return Normal). A test case has been added to the mono/tests directory.
* Use a copy of creation_flags so local modifications aren't propagated
* Use pthread_setschedparam as OSX doesn't support pthread_setschedprio
* An enhancement to the thread priority work added earlier. This will support starting a thread with a specified priority. Currently, the thread will start with the priority of the creator. The semantics of threads allow you to specify the priority of a thread before it has started. Therefore, we take note of this value at thread creation time.
* Missed committing this file the first time
* Correct typo
* Fix creation_flags reference
* MonoThreadParm really should not be in objects-internal
* Place priority in MonoInternalThread where it can be accessed by GetThreadPriority(). This enablses the priority to be set/retrieved before the thread is started. It also ensures that new threads default to a priority of THREAD_PRIORITY_NORMAL rather than inheriting the parent thread's priority.
* Revert changes to MonoInternalThread/Thread.cs. Properly use the handle for thread lookup. Initialize priority at thread creation time. Use stored value of priority if thread has not been started.
* Add code to handle retrieving the thread priority from a started thread that had been set before thread had started. This is necessary as before the thread is started the priority value can be manipulated. This value is stored in the MonoThread structure. Before the thread is started the value can be interrogated so we return this value rather than invoking the GetThreadPriority() API. When a thread is started this value is used to set the threads priority (if scheduling policy is SCHED_FIFO or SCHED_RR). For POSIX threads, after the thread is started we now keep the priority in the _Wapi_thread structure which is located via the thread handle. This structure doesn't exist until after the thread is started so we can't store the value there but after we can cache the priority value there and return it for non-SCHED_[RR|FIFO] threads. This way the expected value will always be set and returned by ThreadPriority property (currently for these threads it will simply return Normal). A test case has been added to the mono/tests directory.
* Use a copy of creation_flags so local modifications aren't propagated
* Use pthread_setschedparam as OSX doesn't support pthread_setschedprio
16 files changed: