Semaphores in DSP/BIOS
in [DSP]
|
From: Randy Yates on 29 May 2010 14:43 Hi Folks, I just realized what would probably be the best solution given the semaphores available in DSP/BIOS. Initialize the semaphore to a 1. Then SEM_pend() on the semaphore at the beginning of the Init() task (this assumes the Init() task runs first at startup), and SEM_post() on the semaphore at the end of the Init() task. As before, all other tasks SEM_pend() on the semaphore, then as soon as the pend is released, post to the same semaphore. This way, if any other tasks run between Init() begin and Init() end, they will block since the pend at the beginning of Init() will have taken the semaphore. And at the end of Init, the pend will allow the first pending task to unblock, it's pend allows the next pending task to unblock, etc., until task N is unblocked and when it posts the semaphore will be left at a 1, ready for the next "resource block" (if any). -- Randy Yates % "How's life on earth? Digital Signal Labs % ... What is it worth?" mailto://yates(a)ieee.org % 'Mission (A World Record)', http://www.digitalsignallabs.com % *A New World Record*, ELO
From: Nils on 29 May 2010 15:14 Randy Yates wrote: > The main point is this: isn't there a "type" of semaphore usually > provided in other OSes which allows multiple tasks to pend on a > "single" post? Hi Randy, I've read the posts you've wrote about DspBios over the past few weeks. Seems like you're currently starting to use it.. If so: You should take a look at the software interrupts. For me they are the swiss army knife of process synchronization. DspBios on it's own already offers a lot, but there are things that you can't directly do with it. One practical example that I once had to deal with: I was gluing together different third party libraries. One was writing it's result to a mailbox, the other one was posting a semaphore. How do you write a consumer task that starts processing results as soon as one of the conditions occur? DspBios does not has as pre-canned solution. My first solution was built upon tasks. I had one helper-task waiting for the mailbox, another helper-task waiting one on the semaphore and both threads signaled a event to a third thread, my consumer. Sounds like a straight forward design, but it didn't worked as expected. My helper threads worked inside the task environment, so it happened that for example my first helper thread read the data from the mailbox and unblocked my consumer-thread, but the consumer thread never started because there was something higher priority running inside one of the third party libraries. Software interrupts solved the problem for me. They life outside the scheduler, so a software interrupt preempts any task. This lets you post multiple semaphores without getting interrupted, it lets you check mailboxes, semaphores and each other blocking DspBios primitive. You can also post semaphores and unblock tasks inside software interrupts. They are much leaner than tasks. You can raise them with conditions (counting or masking). Also they don't block hardware interrupts in any way.. As said: For non trivial scheduling problems a swiss army knife. And easy to use.. Cheers and and have fun, Nils
From: Randy Yates on 29 May 2010 17:45 <sigh> again a few mistakes: > [...] > And at the end of Init, the POST will allow the > first pending task to unblock, it's POST allows the next pending task to > unblock, etc., until task N is unblocked and when it posts the semaphore > will be left at a 1, ready for the next "resource block" (if any). -- Randy Yates % "How's life on earth? Digital Signal Labs % ... What is it worth?" mailto://yates(a)ieee.org % 'Mission (A World Record)', http://www.digitalsignallabs.com % *A New World Record*, ELO
From: Tim Wescott on 29 May 2010 18:00 On 05/29/2010 11:23 AM, Randy Yates wrote: > Tim Wescott<tim(a)seemywebsite.now> writes: > >> On 05/28/2010 03:37 PM, Randy Yates wrote: >>> Thanks to everyone for your responses, but judging by the complexity >>> of your responses, I think you misunderstood my question. >>> >>> The main point is this: isn't there a "type" of semaphore usually >>> provided in other OSes which allows multiple tasks to pend on a >>> "single" post? >> >> Yes. It's called a 'binary semaphore'. Sometimes it's called an >> event' or a 'flag'. A complete RTOS should have both: many have just >> one or the other, along with some weasle-word justification for the >> practice that boils down to "we never need to use the other kind of >> semaphore and we're lazy, so you don't need to use it either". > > Ha! I hear ya' Tim. > > Well, it turns out DSP/BIOS _does_ have a "binary semaphore." The > problem is, it's not the type of binary semaphore I need. > > From the DSP/BIOS API Reference Manual for SEM_pendBinary(): > > SEM_pendBinary and SEM_postBinary are for use with binary > semaphores. These are semaphores that can have only two states: > available and unavailable. They can be used to share a single resource > between tasks. They can also be used for a basic signaling mechanism, > where the semaphore can be posted multiple times and a subsequent call > to SEM_pendBinary clears the count and returns. Binary semaphores do > not keep track of the count; they simply track whether the semaphore > has been posted or not. > > [...] > > If the semaphore count is non-zero (available), SEM_pendBinary sets > the count to zero (unavailable) and returns TRUE. > > If the semaphore count is zero (unavailable), SEM_pendBinary suspends > execution of this task until SEM_post is called or the timeout > expires. > > So what I need is not something that can handle multiple posts and one > pend, but rather something that can handle multiple pends and one post! MT! (that's the spelling) from US Software used to do that -- their binary semaphore (they called it an "event") had a 'regular' pend, and a 'check', where you could pend but not clear. I think it's Nucleus now, but I disremember. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Not Really Me on 3 Jun 2010 11:11
Randy Yates wrote: > Thanks to everyone for your responses, but judging by the complexity > of your responses, I think you misunderstood my question. > > The main point is this: isn't there a "type" of semaphore usually > provided in other OSes which allows multiple tasks to pend on a > "single" post? > > --Randy Wow, this may be stating the obvious, but there sure don't seem to be many DSP/BIOS users on here. -- Scott Validated Software Lafayette, CO __________ Information from ESET NOD32 Antivirus, version of virus signature database 5169 (20100603) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |