Multiple tasking question

[twesthoff]

Don,
FYI, in the manual on the ResetProcessor page, under Compatibility it says:
BasicX does not support Register.ResetFlags.
Tom

[dkinzer]

BasicX does not support Register.ResetFlags.

I believe that it is true that the BasicX compiler does not support Register.ResetFlags and that Register.ResetFlags is not available in BasicX compatibility mode of the ZBasic compiler. Do you have any information to the contrary?

[twesthoff]

Do you have any information to the contrary?

It seemed to me that it was not applicable to that page, since it it did not mention it anywhere on that page. The title of the page is ResetProcessor, not Register.ResetFlags. I thought you meant it did not support ResetProcessor. There is nothing on the page that would indicate they are related except the word Reset is common to both of them.
I just thought it may have been a typo and you would like to know about it.

[dkinzer]

It seemed to me that it was not applicable to that page, since it it did not mention it anywhere on that page.

Actually, it does mention it specifying that Register.ResetFlags will indicate that a watchdog reset has occurred.

[twesthoff]

Actually, it does mention it specifying that Register.ResetFlags will indicate that a watchdog reset has occurred.

My mistake, it just didn't seem consistant. I didn't know that ResetProcessor was supported in BasicX. Of course I have quit using all of my BX stuff long ago, so it doesn't matter.

[pjc30943]

Just updating this thread based on a new question of mine, to not require a new post when it's virtually the same as the present one.

Let's say two tasks call sub Common(), which should never be accessed more than once at the same time. Unfortunately this function is still called again while another task already has access to it, despite semaphore usage.

Any thoughts on what I'm doing incorrectly?

main:

Code: Select all

public CommonSem as boolean
CommonSem = false

Code: Select all

sub Common()
  debug.print "O"
  ...
  debug.print "F"
end sub

Both Task #1 and task #2 have this code:

Code: Select all

...
do
  ...
  do until ( semaphore(CommonSem) )
    sleep 0.0
  loop
  call Common()
  CommonSem = false
  ...
loop

This seems like it should adequately lock Common(), yet the following string is still seen in the terminal--indicating a second call before the first one terminates. When correct, the pattern should always be OFOF only, if Common was called strictly in succession.

Code: Select all

...
O
O
F
F
...

EDIT: since common() exits before all characters in the queue are physically sent out to the terminal, "OOFF" may not indicative of what happens--though queue order should still be preserved. Either way, other symptoms also show that both tasks are accessing at the same time.

[mikep]

Just updating this thread based on a new question of mine, to not require a new post when it's virtually the same as the present one.

I could not reproduce the problem using the sample code you gave. Perhaps you can give a cutdown example that shows the problem. I suggest starting a different thread.

[Don_Kirby]

It seems to me that your usage is correct. My suggestion is to add some delay (perhaps 0.5 second) after each call to Debug.Print to give the queue time to empty, and to slow the process down to a more human speed. It may help to uncover the problem.

Code: Select all

sub Common()
  debug.print "O"
  Call Sleep(0.5)
   ...
  debug.print "F"
  Call Sleep(0.5)
end sub 

Alternatively, you could wait for only the amount of time needed to empty the queue, therefore negating any effect of baud rate.

Code: Select all

sub Common()
	debug.print "O"
	Do While StatusQueue(Register.TxQueue)
		Call Sleep(0)
	Loop
	debug.print "F"
	Do While StatusQueue(Register.TxQueue)
		Call Sleep(0)
	Loop
end sub 

-Don