Pumpkin, Inc.

Pumpkin User Forums

u.runStatus.state possible problems?

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

u.runStatus.state possible problems?

Postby luben » Mon Jul 09, 2001 1:27 am

Hello,

Some thoughts about RunStatus.

What I saw that is written for the SALVO.H is that it keeps (it’s a copy of) the status of the current task's state when it was made ready to run and it’s used only while task is running. Maybe I wrong, because English is not my native language, so if I wronged and misunderstood, I beg you for a pardon.

In OSTimedOut() you use u.runStatus.state value to determine wheather the task is timed out or running. My question is – if this status is before the task is ready to run (the status in the moment when it returns the control to OSSched() , not from OSSched to the task), that means – time out will hold the old information, I mean – from the previous moment. This will delay all statuses with one “schedule” call.

So, if you have

OS_WaitXYZ(Event_A,……); // and this event returns OSTIMED_OUT
OS_WaitXYZ(Event_B,……); // that will not return timeout (event already signaled)

After execution of second OSWaitXYZ() the u.runStatus.state will hold the OSTIMED_OUT value. Only after new call to OSSchedule() the value will become correct.

As I mentioned in the beginning of the article, all my thoughts are based on the SALVO.H and maybe I wrong somewhere. From other side, seeing that some mistakes were found around this variable, it’s possible that other one still exists (just my bitter experience – mistakes are never going alone, they have some character and like to make “society” and groups).

I think for you is not big deal to check if my fears have some reason or not onto your source files. Because I know that your comments (from the SALVO.H) are always very clear and exactly, maybe in this case is or wrong comment, or wrong program.

By the way, writing this letter I got a way how I can check if this is true or not – if before calling OSWaitXYZ() (well, without timeouts) I do the following (you know - the best way to check something is to make real tests):

code:

OStypeTcbP tcbPoint; // define new pointer
Byte pro; // variable that will keep the result

tcbPoint = TASK_ID; // set in pointer address of current TCB
OScTcbP->u.runStatus.state = 0; // will set some impossible value

OSWaitXYZ(…); // wait an event
// would be good if can be checked for TIMEDOUT or not, but it’s up to you – I can do only for event

pro = OScTcbP->u.runStatus.state; // read value


So, if I read the value in pro and the value still remains 0 – SALVO has problem, if it’s refreshed – it’s OK.

Regards
Luben

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

Re: u.runStatus.state possible problems?

Postby aek » Tue Jul 10, 2001 8:28 am

There are no known problems with runStatus.state.

What the source code will reveal is that runStatus.state is (newly) redefined in the scheduler immediately immediately prior to resuming execution in a task.

Therefore your test code snippet won't work, as runStatus.state will be redefined to be a valid state (usually OSTA_ELIGIBLE, might be OSTA_TIMEDOUT) immediately before the task resumes execution after OS_WaitXyz().

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

Re: u.runStatus.state possible problems?

Postby luben » Tue Jul 10, 2001 10:05 am

Hello,

From what I read today in the forum I still think that u.runStatus.state can make you problems. And you gave me the idea where could be exactly the problem. You wrote that OS_WaitXYZ() don't contex switch is event already exists. So here is the moment.

Imagine you have OS_WaitXYZ(EVENT1) and you return with timeout from it. And immediately after that you have OS_WaitXYZ(event2) and event2 already signalled. From what you told me today the second OS_WaitXYZ() will not contex switch, because event already signalled. That means - u.runStatus.state will not be updated and you will have problems using OSTimedOut(), at least it will have the value from OS_WaitXYZ(EVENT1).. If this value is what you need - then OK, but if not.... then boom

But I feel that this small exeption of OS_WaitXYZ() (that don't contex switch is event exists) for sure ware some problems.

It's not big deal for you to make this and to check if my doubts are correct....

code:

// BINSEM1 should be not signalled
// try to avoid any other contex switches between described commands

OS_WaitBinSem(BINSEM1, time_100ms, LABEL1);
// this will produce OSTATIMED_OUT

OSSignalBinSem*BINSEM2);

OS_WaitBinSem(BINSEM2, time_1s, LABEL2);

// if U.runstatus.state is not refreshed - OSTimedOut()will return wrong result

if (OSTimedOut())
BOOOOM :-( // this could happen if not rfreshed
else
smile :-) // this is the correct result


Unfortunately I can't check this on DEMO.

It's not big deal to make you this into project and to check it in minutes and to calm me down.

I believe that the behaviour of OS_WaitXYZ() and this exception (don't contex switch)should be checked in this example. In my programs I try to avoid any exeptions - they are the biggest sources of any kind of mistakes. By the way up to today I thougth that OS_WaitXYZ() always returns the control to scheduler, after I read the manual I saw that you're right - everything is written in details there. So, it's my fault that I misunderstood OS_WaitXYZ().

Anyway, check if my doubts are right or not...

Regards
Luben

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

Re: u.runStatus.state possible problems?

Postby luben » Tue Jul 10, 2001 10:10 am

Hello,

I think that you should change the way of writing OS_WaitXYZ() to OS~WaitXYZ().... and to say that sometimes it contex switch, sometimes not (~) will bring idea that this could be not pure contex switch.

I'm just kidding....
Luben

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

Re: u.runStatus.state possible problems?

Postby luben » Wed Jul 11, 2001 7:02 am

Hello,

Even if such mistake in SALVO exists it could be fixed very easy in SALVO.H

Let's take for example the definition of OS_WaitBinSem

code:

#define OS_WaitBinSem(ecbP, timeout, label)
while ( OSWaitEvent(ecbP, OSEV_BINSEM, timeout) == OSERR_EVENT_NA )
OS_Yield(label)

with simple adding to it of one line the problem should disappear at all (if such problem exists)

code:

#define OS_WaitBinSem(ecbP, timeout, label)
OScTcbP->u.runStatus.state == OSTA_ELIGIBLE;
while ( OSWaitEvent(ecbP, OSEV_BINSEM, timeout) == OSERR_EVENT_NA )
OS_Yield(label)

Adding this new line just forces the value of OScTcbP->u.runStatus.state to OSTA_ELIGIBLE in case if the event doesn't contex switch.


Anyway, will be better if such mistake don't exists in SALVO. From my stay in Japan I learned - if you found some problem (even just possible) - try to find a cure immediately. So, in all cases SALVO will be OK :-)

For sure you'll have the last word and I'll be happy if these were just only my fears and doubts.

Regards
Luben

[This message has been edited by luben (edited July 11, 2001).]

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

Re: u.runStatus.state possible problems?

Postby aek » Wed Jul 11, 2001 8:51 am

quote:
Imagine you have OS_WaitXYZ(EVENT1) and you return with timeout from it. And immediately after that you have OS_WaitXYZ(event2) and event2 already signalled. From what you told me today the second OS_WaitXYZ() will not contex switch, because event already signalled. That means - u.runStatus.state will not be updated and you will have problems using OSTimedOut(), at least it will have the value from OS_WaitXYZ(EVENT1).. If this value is what you need - then OK, but if not.... then boom

The scenario you suggest is a valid one, but I believe it's taken care of in OSWaitXyz() (not the macro OS_WaitXyz()) -- I'll check on it shortly and get back.

quote:
I think that you should change the way of writing OS_WaitXYZ() to OS~WaitXYZ().... and to say that sometimes it contex switch, sometimes not (~) will bring idea that this could be not pure contex switch.

Very funny ... :-)

[This message has been edited by aek (edited July 11, 2001).]

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

Re: u.runStatus.state possible problems?

Postby luben » Thu Jul 12, 2001 8:10 am

Excuse me, I wronged the "fixing of possible mistake", this should be the right one.

code:

#define OS_WaitBinSem(ecbP, timeout, label)
OScTcbP->u.runStatus.state = OSTA_ELIGIBLE;
while ( OSWaitEvent(ecbP, OSEV_BINSEM, timeout) == OSERR_EVENT_NA )
OS_Yield(label)


And of course - you have to care for other event services too.

Breaking the hard law of contex switching (sometimes happens, sometimes not) is one absolutely dangerous zone. As Murphy law says - it should be at least one hidden mistake there (he was optimist). Try to remove all exception. Well, I'm sure that you'll check this and if you were careful when you wrote the code it will stay only like article in the forum... "fears about SALVO" :-) If some problem exists - then OK again, they will be removed....

And by the way, if this mistake exists in SALVO2.2 it should exist in SALVO2.1 too.... sounds scary, huh? I think that you can check this even on MPLAB emulator - you don't need to run ICE.

Regards
Luben

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

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

Re: u.runStatus.state possible problems?

Postby luben » Fri Jul 13, 2001 7:59 am

Hello,

My fixing of OS_WaitXYZ() is not the best, but don't forget that what I have in my computer is SALVO.H, so I can't go deeper. If you send me the source of event.c (where I hope resides the code of event analizing routines) I can bring more ideas. Dont' forget that two brains think better then one and they can see the problem from different view points.

Have you a nice weekend.
By the way next week I'll go for 20 days vacation on the Black sea... you know - time for windsurfing...

Luben

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

Re: u.runStatus.state possible problems?

Postby aek » Fri Jul 13, 2001 10:42 am

quote:
Breaking the hard law of contex switching (sometimes happens, sometimes not) is ...

The Salvo User Manual states very clearly that context switches for OS_WaitXyz() will occur only if the event is not available. See the Title and Description for OS_WaitBinSem() in Chapter 7 * Reference.

I will re-state the "hard law of context switching" here: Only Salvo services with the "OS_" prefix may cause a context switch to occur. See the description for the service for further details.

All of the OS_Xyz() services are clearly documented as to when a context switch will occur. Some are unconditional (e.g. OS_Delay() and OS_Yield()), and some are dependent on the value of the event (e.g. OS_WaitBinSem()), as one would expect in an event-based RTOS.

Regarding the problem with OSTimedOut() -- you are correct that Salvo v2.2 and earlier will display the (undesireable) behavior you describe. Your fix for OS_WaitBinSem() will work, but it's costly, as it's in-line in the macro. We will provide a fix in the next Salvo update.

-------
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 2 guests

cron