Open GoogleCodeExporter opened 9 years ago
Could you please give more details?
Original comment by mbb...@gmail.com
on 26 Jul 2011 at 2:37
For example, in function rt_sem_release(...) is present critical sectionЖ
/* disable interrupt */
temp = rt_hw_interrupt_disable();
RT_DEBUG_LOG(RT_DEBUG_IPC,
("thread %s releases sem:%s, which value is: %d\n", rt_thread_self()->name,
((struct rt_object*)sem)->name, sem->value));
if ( !rt_list_isempty(&sem->parent.suspend_thread) )
{
/* resume the suspended thread */
rt_ipc_list_resume(&(sem->parent.suspend_thread));
need_schedule = RT_TRUE;
}
else sem->value ++; /* increase value */
/* enable interrupt */
rt_hw_interrupt_enable(temp);
Between functiones rt_hw_interrupt_disable() and rt_hw_interrupt_enable() is
very much the code, which grow the latency of interrupt.
Original comment by ed...@bk.ru
on 27 Jul 2011 at 7:57
in eCOS the same semaphore is realized thus:
void Cyg_Binary_Semaphore::post()
{
// Prevent preemption
Cyg_Scheduler::lock();
CYG_INSTRUMENT_BINSEM( POST, this, 0 );
state = true;
if( !queue.empty() ) {
// The queue is non-empty, so grab the next
// thread from it and wake it up. The waiter
// will clear the flag.
Cyg_Thread *thread = queue.dequeue();
thread->set_wake_reason( Cyg_Thread::DONE );
thread->wake();
CYG_INSTRUMENT_BINSEM( WAKE, this, thread );
}
// Unlock the scheduler and maybe switch threads
Cyg_Scheduler::unlock();
}
Here the critical section is disposed between Cyg_Scheduler::lock() and
Cyg_Scheduler::unlock(), wherewith the latency of interrupts very low.
Original comment by ed...@bk.ru
on 27 Jul 2011 at 12:09
Original issue reported on code.google.com by
ed...@bk.ru
on 25 Jul 2011 at 10:34