rtems - RTEMS Kernel, file-systems, drivers, BSPs, samples, and testsuite.

	Commit message (Collapse)	Author	Age	Files	Lines
*	score: Use thread state lock for current state	Sebastian Huber	2016-05-12	1	-2/+2
\| \| \| \| \| \| \|	In addition protect scheduler of thread by thread state lock. Enables use of scheduler per-instance locks. Update #2555.
*	score: Add scheduler acquire/release	Sebastian Huber	2015-03-24	1	-3/+3
\| \| \| \| \| \| \|	This is currently a global lock for all scheduler instances. It should get replaced with one lock per scheduler instance in the future. Update #2273.
*	score: Remove scheduler parameter from most ops	Sebastian Huber	2014-06-23	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \| \|	Remove the scheduler parameter from most high level scheduler operations like - _Scheduler_Block(), - _Scheduler_Unblock(), - _Scheduler_Change_priority(), - _Scheduler_Update_priority(), - _Scheduler_Release_job(), and - _Scheduler_Yield(). This simplifies the scheduler operations usage.
*	score: PR2181: Add _Thread_Yield()	Sebastian Huber	2014-06-12	1	-0/+41
	The _Scheduler_Yield() was called by the executing thread with thread dispatching disabled and interrupts enabled. The rtems_task_suspend() is explicitly allowed in ISRs: http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/Interrupt-Manager-Directives-Allowed-from-an-ISR.html#Interrupt-Manager-Directives-Allowed-from-an-ISR Unlike the other scheduler operations the locking was performed inside the operation. This lead to the following race condition. Suppose a ISR suspends the executing thread right before the yield scheduler operation. Now the executing thread is not longer in the set of ready threads. The typical scheduler operations did not check the thread state and will now extract the thread again and enqueue it. This corrupted data structures. Add _Thread_Yield() and do the scheduler yield operation with interrupts disabled. This has a negligible effect on the interrupt latency.