Page 1 of 1

How can I RESET BinSemaphore

PostPosted: Mon Dec 11, 2000 8:22 am
by luben

The command to set one semaphore is OSSetBinSem(....). Some task could use this information to do something. Imagine that in one project I set some semaphore and then I see that I have to clear it without doing anything. Is it the only one way to do this with OSWaitBinSem(.....). If the semaphore is not set this way of reset could wait a long time (TimeOut). And what about semaphores like counters - can I set them to some predefined value? Or I can only increment/decrement their content.

And about the message queue - can I access some messages inside the queue, or I should read it one by one (stack structure). If very important message appears how I could manage it - the stack structure don't care for any priority, except - first in/first out. The easiest way, what I see is to organize second queue.. something like "VIP queue".
If your message queue is not stack structure, but message pool, maybe you'll need one additional byte to define a message time stamp and indentification of the position (occupied/free for record). In such message pool every task can take what it wants.



Re: How can I RESET BinSemaphore

PostPosted: Tue Dec 12, 2000 9:05 am
by aek
Hi Luben.

1) You can reset a binary semaphore by calling

OSCreateBinSem(MY_SEM, 0);

You can "reset" any event in a similar manner. However, you should only do this if you are certain that there are no tasks waiting for the event.

When using a (counting) semaphore, you can initialize it (via OSCreateSem()) to any value. After that, the RTOS automatically increments or decrements the semaphore based on calls to OSSignalSem() and OS_WaitSem().

As you probably know, semaphores are a very tightly defined concept. Resetting or changing their absolute values "on-the-fly" is incompatible with their intended use.

2) The message queue is FIFO-based -- the order in which messages are received is the same as the order in which they are sent. We chose to implement it this way. Some other RTOSes do it in other ways, or multiple, configurable ways -- all of that leads to larger code and RAM size, of course.

One thing you could do is obtain the message via OS_WaitMsgQ(), and then re-enqueue it via OSSignalMsgQ() if it's not the message you're looking for.

Keep in mind that with Salvo, tasks wait on events based on _task_ priority. Therefore if multiple tasks are waiting on a message queue, even if the messages were prioritized, the highest-priority task would get the first / highest-priority message.

In future releases of Salvo we would like to add additional "peek" functionality -- like OSTestSem().