Mindboards

Does the NBC/FW run as a "preemptive scheduler" or as a "run until program yields"?

For you folks that may not CompSci degrees:
- "preemptive scheduling" means that, in a multi-task (mult-thread) environment, you can loose control of the processor at any time (unless you take explicit steps to not loose it - mutexes, etc.)
- "run until program yields" means that, in the same environment, a piece of code can not loose control until it does a Wait of some kind. You have implicit control of the processor until you want to give it up.

It uses a preemptive scheduler.

The FW processes 20 opcodes by default before switching to the next task, and earlier if a Wait() or Yield() is called. (The opcodes can vary based on the assigned task priority.)

John Hansen has written some posts about it somewhere on this forum and other places. Maybe try and search for that discussion on Yield()... (I realize that was all incredibly vague.)

OK, both mattallen37 and muntoo. That question was a prelude to another question - some of us have been using the following code: to send data from a Master to a Slave. However, this code isn't really safe. (mattallen37, you were asking about "safecall" - this is another aspect.) Between the "until" and the start of the send, the task could be preempted and, when it gets to the send, the connection is no longer idle. Then what happens? (No, I'm not completely naive about this. Another "leading question".) I've looked at the send code and the first thing it does is acquire __RemoteMutex. So, the send itself is safe, but, if the connection has gone busy, it fails. I thought it would work, but there's a non-trivial probability that it won't work. I'm not going to make any conclusions because I may be completely wrong about this.

Wouldn't that only happen if you are making BT calls in multiple tasks simultaneously? In that case, you can use a mutex to protect whatever needs protection.

Well, yes. But, the BT protocol is written to allow multi-threading, else it wouldn't have the acquire mutex right at the start. The entire readremote is protected by a mutex. What I'm suggesting is that there should be an option to make the NBC code something like this: This assumes that each comm channel is independent, which I'm not so sure is actually true. John should be able to verify that.

This code ensures that the comm channel is idle before even trying the rest of it.

What can make the comm channel busy besides another read/send?

The way I wrote the API functions does not define the bluetooth protocol. I'm only using mutexes to protected shared global variables (iirc) and not to make these functions truly thread safe based on the underlying firmware's bluetooth subsystem behavior.

You must write your code so that you never try to send a message if the underlying bluetooth subsystem is busy working on another bluetooth send/receive task. The best and smartest and easiest way to do that is to not fiddle around with bluetooth on multiple threads.

I don't think the connections are truly independent but I would need to look at the firmware source code again to remember for certain.

Don't try to over think using Bluetooth. It is really extremely simple to use and very reliable so long as you keep your program from doing crazy things like reading mailboxes on multiple threads.

John Hansen

but what if multithreaded programs demand to use BT remote functions independently?
1 task reads local and remote sensors,
1 2nd task controls local and different remote motors depending on sensor events ("Remote_OnFwd until Remote_Touch is pressed" or "...until (RemoteLightSensorRaw>500)"
1 3rd task reacts to user interrupts and has to follow it's instructions like send BT messages to any other device for what purpose ever.

BT has just 1 sense: muliply the number of all I/O devises of the the local NXT by all numbers of all NXTs overall: 4 NXTs= 12 motors and 16 sensors to be controlled and read.

I will not restrict my programs on what they do locally with my I/O devices, and I won't restrict them what they do on remote NXTs.

BT must not restrict what tasks ever need to do - what tasks may do locally, they must be able to do on remote devices (slaves) as well. BT messaging must support this safely.

afanofosc wrote: It is really extremely simple to use and very reliable so long as you keep your program from doing crazy things like reading mailboxes on multiple threads.

Sorry, John, but my mind simply designs multi-threaded communication apps. I've been doing it for many years and It hurts when I tell the design part of my head - "single thread".

I'm going to continue to tinker with this the next time I need to do an NXT/NXT application. I think I've got a way to make it thread safe and reliable, but I'm not going to post it here.

I've learned a lot about NXT/NXT BT here at Mindboards. When I first came on here, I was having trouble making it work at all. Now, I think I can make it work like I want.

Sorry, John, but my mind simply designs multi-threaded communication apps. :ugeek: I've been doing it for many years and It hurts when I tell the design part of my head - "single thread". :)

+1