* [ECOS] Thread suspend when scheduler is locked. @ 2012-06-20 18:23 Sergei Organov 2012-06-21 9:00 ` [ECOS] " Sergei Organov 0 siblings, 1 reply; 8+ messages in thread From: Sergei Organov @ 2012-06-20 18:23 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ECOS] Re: Thread suspend when scheduler is locked. 2012-06-20 18:23 [ECOS] Thread suspend when scheduler is locked Sergei Organov @ 2012-06-21 9:00 ` Sergei Organov 2012-06-21 10:33 ` Nick Garnett 0 siblings, 1 reply; 8+ messages in thread From: Sergei Organov @ 2012-06-21 9:00 UTC (permalink / raw) To: ecos-discuss 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. -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ECOS] Re: Thread suspend when scheduler is locked. 2012-06-21 9:00 ` [ECOS] " Sergei Organov @ 2012-06-21 10:33 ` Nick Garnett 2012-06-21 11:51 ` Sergei Organov 0 siblings, 1 reply; 8+ messages in thread From: Nick Garnett @ 2012-06-21 10:33 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ECOS] Re: Thread suspend when scheduler is locked. 2012-06-21 10:33 ` Nick Garnett @ 2012-06-21 11:51 ` Sergei Organov 2012-06-21 12:48 ` Nick Garnett 0 siblings, 1 reply; 8+ messages in thread From: Sergei Organov @ 2012-06-21 11:51 UTC (permalink / raw) To: ecos-discuss Nick Garnett <nickg@calivar.com> writes: > 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. > > [...] > 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? -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ECOS] Re: Thread suspend when scheduler is locked. 2012-06-21 11:51 ` Sergei Organov @ 2012-06-21 12:48 ` Nick Garnett 2012-06-21 14:57 ` Sergei Organov 0 siblings, 1 reply; 8+ messages in thread From: Nick Garnett @ 2012-06-21 12:48 UTC (permalink / raw) To: ecos-discuss 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. 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 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ECOS] Re: Thread suspend when scheduler is locked. 2012-06-21 12:48 ` Nick Garnett @ 2012-06-21 14:57 ` Sergei Organov 2012-07-01 2:45 ` Jonathan Larmour 0 siblings, 1 reply; 8+ messages in thread From: Sergei Organov @ 2012-06-21 14:57 UTC (permalink / raw) To: ecos-discuss 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. In fact I use this feature for very special purpose and can re-design my code to avoid it. -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ECOS] Re: Thread suspend when scheduler is locked. 2012-06-21 14:57 ` Sergei Organov @ 2012-07-01 2:45 ` Jonathan Larmour 2012-07-02 10:13 ` Sergei Organov 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Larmour @ 2012-07-01 2:45 UTC (permalink / raw) To: Sergei Organov; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ECOS] Re: Thread suspend when scheduler is locked. 2012-07-01 2:45 ` Jonathan Larmour @ 2012-07-02 10:13 ` Sergei Organov 0 siblings, 0 replies; 8+ messages in thread From: Sergei Organov @ 2012-07-02 10:13 UTC (permalink / raw) To: ecos-discuss Jonathan Larmour <jifl@eCosCentric.com> writes: > 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. No, in fact I didn't care. For 2-level interrupts servicing eCos implements, complete set of features would be: 1. Disable/restore ISRs (also effectively does 2 and 3) 2. Disable/restore DSRs (also effectively does 3) 3. Disable/restore threads switching all these states being thread-local. Current scheduler lock feature is close to (2), except that it introduces surprising behavior I was referring to. The main idea behind disabling preemption is that as soon as system function that could lead to DSRs invokation and/or task switch is called explicitly, DSRs are run and taks will be switched. This is what does not happen in some of current eCos system functions. Note that even though DSRs are disabled when scheduler is locked, given scheduler lock is thread-local, even timed waits should work out of the box for the thread that locks scheduler as scheduler is still enabled when this thread sleeps. > 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. Yes, reserving highest priority for that purpose would work, provided scheduler supports dynamic priority change. > 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... I believe it could. Hopefully it's just a matter of adding a few explicit calls to reschedule() where appropriate in the eCos kernel code as waits on primitives such as semaphores do work as expected, so all the required functionality is apparently already there. -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-07-02 10:13 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-20 18:23 [ECOS] Thread suspend when scheduler is locked Sergei Organov 2012-06-21 9:00 ` [ECOS] " Sergei Organov 2012-06-21 10:33 ` Nick Garnett 2012-06-21 11:51 ` Sergei Organov 2012-06-21 12:48 ` Nick Garnett 2012-06-21 14:57 ` Sergei Organov 2012-07-01 2:45 ` Jonathan Larmour 2012-07-02 10:13 ` Sergei Organov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).