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 15:57, Sergei Organov wrote:
> Nick Garnett <nickg@calivar.com> writes:
> 
>> On 21/06/12 12:51, Sergei Organov wrote:
>>> Nick Garnett <nickg@calivar.com> writes:
>>
>>>> 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.
>>>
>>> So, there is no way in eCos to just disable _preemption_? I.e.,
>>> (temporarily) switch from preemptive to cooperative multi-threading?
>>
>> Not really. You could try implementing a new scheduler that only did
>> context switches when a yield function is called. If you disable
>> timeslicing and run all your threads at the same priority they will
>> essentially run round-robin and only lose the CPU when they explicitly
>> suspend, although higher priority threads will still preempt.
> 
> No, I need full-featured preemptive scheduling with multiple real-time
> thread priorities. I thought "disable preemption" feature is pretty
> standard among RTOSes and have it in my RTOS abstraction layer,
> implemented as a call to cyg_scheduler_lock() in eCos as disabling
> preemption is what description of the call claims.

The problem with any sort of abstraction layer is matching what you mean with
what exactly is provided. In particular does disabling pre-emption mean that
DSRs should be disabled too? From what you're saying, I think you mean that
DSRs should still be allowed.

So if you just want to make sure no other threads can pre-empt this one, then
surely the answer is to temporarily change its thread priority to 1, and
change it back when you're done. And reserve priority 1 for threads in this
situation.

If multiple threads can disable pre-emption at the same time, but still be
able to suspend themselves, then you would have to work out what that really
is meant to mean. It's not clear what would be correct behaviour in that
situation in general, so you would have to decide what that means in your
specific case.

> In fact I use this feature for very special purpose and can re-design my
> code to avoid it.

Good, but I do wonder if that could have been avoided...

Jifl
-- 
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.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

-- 
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]