This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Thread suspend when scheduler is locked.



On 21/06/12 10:00, Sergei Organov wrote:
> A few clarifications below.
> 
> Sergei Organov <osv@javad.com> writes:
>> Hello,
>>
>> In the following sequence:
>>
>>   cyg_scheduler_lock();
>>   cyg_thread_suspend(thread);
>>
>> the second call returns immediately that is very surprising. Is it a bug
>> or fature?
> 
> 1. 'thread' is the current thread being executed so the suspend call asks
>     thread for suspending itself.
> 
> 2. cyg_thread_delay(delay) returns immediately no matter what is 'delay'
>    value.
> 
> 3. On the other hand, waiting on a primitive such as closed semaphore
>    works fine.
> 
> Looks like a bug to me.


The form of many of these simple functions is to lock the scheduler,
alter whatever state is appropriate, and then unlock the scheduler, with
the understanding that any scheduling may happen at that point.
Semaphore waits and other things are slightly different because they
have changes to state to make after the wait, and need to retain the
lock across it.

In the cases you cite, any scheduling consequences of the calls made
while the scheduler lock is claimed will occur when you finally unlock
the scheduler yourself.

One can argue that this is useful functionality, since it allows you to
make a number of system state changes atomically under the scheduler
lock. However, I don't actually know of any examples where this has been
done, except in DSRs.

Essentially locking the scheduler yourself is like running in a DSR,
there is only a limited number of calls it makes sense to use, and their
effects may be deferred until the scheduler lock returns to zero.

While it might be possible to rewrite some of these routines to work
even when the scheduler lock is already claimed, it would make them
considerably more complex, larger, and thus less maintainable.



-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]