Arbitrator and Busy Waiting

[simon.fischer]

Hi all,

first of all: Thanks for this great piece of software.

From reading the documentation of the Arbitrator class, I have undersood that the Arbitrator is permanently monitoring its Behaviours, asking them whether they want to be active. (Hope this is right, I did not look into the code.) Although I guess that it Thread.yield()s now and then, this still means that this is basically a busy waiting approach. What was the reason for this design decision? In particular, this means that the behaviours cannot check whenever takeControl() is called, because in theory the condition necessary to trigger this behaviour might have been missed already.

If I would have implemented from scratch (actually I did not expect this library to come with high-level utilities for behaviour programming, so this was in fact a positive surprise), I would probably have taken an event-driven approach where the arbitrator listens for changes in priority or changes of an equivalent of takeControl() and suppress()es the current activity when necessary. Is there any reason in the leJOS environment why such an approach would not be recommended?

Best,
Simon

[gloomyandy]

Hi Simon,
I wasn't involved in the design of this class but I can provide some pointers as to why this approach was taken...
1. It is very simple. Take a look at the source, there is very little to it.
2. With an event driven approach something still has to trigger the event, what would do this? The leJOS sensor framework is basically a polled system, so if the Arbitrator class does not provide the polling then something else will have to.
3. I'm not sure I understand your statement "this means that the behaviours cannot check whenever takeControl() is called, because in theory the condition necessary to trigger this behaviour might have been missed already". If you mean that you may miss an external event because takeControl was not called at the right time, then yes this is true, but this is also the case of any system you use. How would having events make things any easier? If the physical event is a some sort of transient then you are always going to have problems detecting it with leJOS. Even if you have a thread that is doing nothing other than monitor a sensor there is no way to ensure that the system is not off doing something else at the critical moment. Luckily the majority of events that need to be detected are not of this nature, if you are too close to a wall then the wall will not disappear if you look a little later.
4. If you do want to have other threads that handle sensors etc. It is very easy to have them use some form of event/flag setting mechanism to trigger the detection system used.

As always you have the source and can easily change things or add your own implementation, so if the current system does not work for you, you can add your own alternative (be sure to tell us all about it when you have it working).

Andy

[simon.fischer]

Hi Andy,

thanks for your response. I was not criticizing the aproach, I just want to make sure I understand correctly the recommended approach in the environment I am using. There are probably good reasons for this (and you gave some), and I do not want to break with the established techniques thoughtlessly.

1. Right.
2. That is of course true. But as I understand, a http://lejos.sourceforge.net/p_technologies/nxt/nxj/api/lejos/nxt/SensorPortListener.html can be added to the sensor, right? Of course that may require a separate thread, and callbacks may come back to my Behaviour in that thread, but the additional thread is now hidden farther away from the caller
3. Yes, you understand that correctly. If the Behaviour checks whether the touch sensor is pressed, it may be pressed only for 10ms during which takeControl() was not called. (I understand this is unlikely, but you get the point.)
4. Yes, thanks.

Ok. Just for playing around with it (and I guess that's what we are doing here ), I will try it out. I will probably even inherit from Behaviour, so my behaviours can be used in both environments, and provide a simple adapter to use generic Behaviours in my version. I'll share my experiences.

Best,
Simon

[gloomyandy]

Ah I wondered how long it would be before Sensor Listeners came up. Do a few searches on the forum to see what I think of them and why using them will almost certainly not give you the results you would like...

Andy