Pumpkin, Inc.

Pumpkin User Forums

BUG similar to bombarded case - multiple already signalled events

If you think you've found a bug or other mistake in your Salvo distribution, post it here.

BUG similar to bombarded case - multiple already signalled events

Postby luben » Wed Dec 12, 2001 7:55 am

Hello,

You mean, that in the new SALVO2.3 if I have several OS_WaitXYZ one after other and all they are signalled, the program will behave like that:
1. Don't contex switch on the first OS_WaitXYZ, because it's already signalled - will do some speed up of the whole program execution
2. DO Contex on the second OS_WaitXYZ, despite that it's already signalled.
3. Don't contex switch
4. Do switch... etc.

Did I understend correctly the new SALVO algorythm? If this is the behaviour of the new SALVO - then it's correct and perfect.

By the way, the described case is not exactly "bombarded" case. The Semaphore is not the main reason to happen this. Maybe I should change the example that I gave and to put just 3 BinSem to waiting, and all they are signalled with 1/3 of speed of the whole loop. Imagine that I have 10 BinSem, signalled with 1/10 of the execution of the task time.... it's not high frequency at all.

Here the events are not signalled so quickly. And if I have n events one after other to WAIT, and all they are signalled with speed faster then 1/n of the time of the whole loop time, problem could appear. because n could be 3, 4 and more, the frequency will be 3, 4 times lower then in bombarded case.... it's absolutely possible frequency. It's some kind of new problem, but based on the same reason - "Sometimes contex switch, sometimes not"

But if SALVO2.3 fixed the problem in the right way for bombarded case, this bug will disappear too.

Regards
Luben

[This message has been edited by luben (edited December 12, 2001).]

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: BUG similar to bombarded case - multiple already signalled events

Postby luben » Wed Dec 12, 2001 9:45 am

Hello,

As you remember some time ago I reported about so called "bombarded" case problem with SALVO2.2, that I hope is already solved into SALVO2.3.

Here I'm reporting about one new problem that I found in my last thermal printer project. It has similar source with "bombarding" case, so if you have fixed the "bombarding" case fine, maybe this will be not a bug into the new SALVO 2.3. I'm afraid that we never spoke about it and it's almost sure that it could appear like bug in the newborn SALVO2.3.

Here is the BUG:

- I have in my project 3 events:
. semaphore for coming data from serial port, used to hold FIFO functionality
. BINSEM to show that row already printed and ready to get new data
. BINSEM for share resources of the mechanic

Because of the high speed of RS232 I always have signalled semaphore and data is always waiting on the port. The share resources BIN semaphore is almost always set (it's used only from one other task to do feed and gap find). And the BINSEM that shows row printed is quickly set on too. The structure of the loop shpould look like

code:


while(TRUE) {

while (buffer_of_head_not_filled)
{
OS_WaitSem(SEM_Serial, .......); // this semaphore is practically always signalled

OS_WaitBinSem(BINSEM_Shared,....); // it's almost always SET

OS_WaitBinSem(BINSEM_Printed,.....); // it's set very quickly from ISR after printing

.... do something.....

OSSignalBinSem(BINSEM_Shared); // free resources


}

}


The problem is:
-- WATCHDOG timeout occured - the task doesn't return the control to the kernel for long time. Well, it happens sometimes, sometimes not - that's the problem. It's similar to bombarded case, with this small difference, that here we speak about multiple already signalled events. No contex switch to kernel appears. Of course, after I got where was my problem I fixed it immediately, with one additional OS_Yield(). But for sure if I didn't catch it it could make "bad" things from time to time - I had the luck that my events have very clear and periodic behaviour.

If you remember , when we discussed the bombarded case, I insist to make algorytm :
. OR to contex switch always when OS_WaitXYZ (already set) comes -some slow down will be encountered
. OR to continue, but setting some flag taht will be proceed next OS_WaitXYZ (already set) - if already set - will contex switch, if not - continue program

The best solution is the second one, but I'm afraid that this needs deep changes of SALVO. Even if you fixed the bombarded case for one event, this will be not true for many already signalled events.

I suggest to name this "multiple already signalled events" problem.

Because it's not always clear when 3 and more events could be set simultaneously, it's hard to get when the task will hang and when not. In my case I had to execute a program for character generator, that tooks long time. And if I don't know will I go to kernel or not, I very quickly exeed the WDT period.

The sign "_" is usually connected with contex switch to kernel. OS_WaitXYZ is one exeption of this rule and of course any exeption brings some possible or real bugs. As I remember you smiled when I suggested to put "~" sign for functions that sometimes contex switch, sometimes not.... but I think that this sign will bring clear vision of the user about the possibility of the functions.

Regards
Luben

[This message has been edited by luben (edited December 12, 2001).]

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: BUG similar to bombarded case - multiple already signalled events

Postby aek » Wed Dec 12, 2001 10:41 am

Hi Luben.

This looks like another "bombardment" situation.

For example, if you are signalling the sem faster than the task runs (i.e. the sem never reaches 0), AND both of the binsems are always set, THEN you have a "bombardment" case. From your comments ( //... ), it looks like that's what is happening.

See, if both binsems are always set before the task does the next loop iteration, the task will stay in the loop until SEM_Serial reaches 0. From your description, this never happens, and there's never a reason for the task to context-switch out of the loop. So, an interim fix is to place an OS_Yield() at the bottom of the loop, as you have done. This has been fixed in post-v2.2 code.

Note that the number of events you're waiting on makes no difference -- 1 or 10 "in series", the problem (in v2.2) can still bite.

So, for now, add an OS_Yield(), and later in the next release, it won't be necessary.

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: BUG similar to bombarded case - multiple already signalled events

Postby aek » Fri Dec 14, 2001 6:41 am

In post-v2.2 code, each OS_WaitXYZ is unconditional, i.e. at the start of each OS_WaitXYZ a context switch is always made. Task execution then continues thereafter.

Note that this scheme isn't necessarily optimal when you're waiting on multiple events in series, but it is a universally applicable solution to the problem.

I suppose you could perhaps replace the two binsems with an eFlag instead ... this would improve performance somewhat.

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm


Return to Bug Reports

Who is online

Users browsing this forum: No registered users and 1 guest