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? -- Sergei. -- -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
A few clarifications below.
Sergei Organov <osv <at> 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.
-- Sergei.
--
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
(Continue reading)On 21/06/12 10:00, Sergei Organov wrote: > A few clarifications below. > > Sergei Organov <osv <at> 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(Continue reading)
Nick Garnett <nickg <at> calivar.com> writes: > On 21/06/12 10:00, Sergei Organov wrote: >> A few clarifications below. >> >> Sergei Organov <osv <at> 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. > > [...](Continue reading)
On 21/06/12 12:51, Sergei Organov wrote: > Nick Garnett <nickg <at> 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. But the usual way to make a set of threads work cooperatively is to use a mutex to serialize their execution. Also note that the scheduler lock will also delay or block execution of DSRs. Which is probably not what you want. Trying to make eCos work as a cooperatively scheduled system is likely to be more trouble than it is worth. It wasn't really designed to work that way. -- -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571(Continue reading)
Nick Garnett <nickg <at> calivar.com> writes: > On 21/06/12 12:51, Sergei Organov wrote: >> Nick Garnett <nickg <at> 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. In fact I use this feature for very special purpose and can re-design my code to avoid it. -- Sergei. -- --(Continue reading)
On 21/06/12 15:57, Sergei Organov wrote: > Nick Garnett <nickg <at> calivar.com> writes: > >> On 21/06/12 12:51, Sergei Organov wrote: >>> Nick Garnett <nickg <at> 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.(Continue reading)
Jonathan Larmour <jifl <at> eCosCentric.com> writes: > On 21/06/12 15:57, Sergei Organov wrote: >> Nick Garnett <nickg <at> calivar.com> writes: >> >>> On 21/06/12 12:51, Sergei Organov wrote: >>>> Nick Garnett <nickg <at> 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.(Continue reading)
RSS Feed