dMZX Forums: send "robot" else "label" -> Rejected Requests -> Tracker

While working on MZX recently, I've found a bunch of cases where a certain slight modification/option to the send command would be useful: the ability to detect failure in sending a robot to a certain label (for example, because the label doesn't exist/is zapped or because said robot is lockself'd), sending the original robot to a "failure" label, similar to how TAKE works. This would be quite useful to the "pseudo-worker-producer-threads" approach I'm taking with my robotic projects.

Let's imagine the following hypothetical situation:

. "This is the control robot"
: "dowork"
. "Something here"
send "worker" to "increment"
wait for 1
goto "dowork"
end

Then, we have the following worker robot:

end
: "increment"
lockself
inc "important_counter" by 1
unlockself
end

As you may guess, the lockself and unlockself act as mutexes in this context. Without them, you could have concurrent control robots mess up "important_counter"'s result.

However, let's suppose that when two calls to the worker robot happened simultaneously, you didn't want to simply have one of them not work, and be ignored (as would happen with the above code) and instead want to force the controller robot that called it to wait until the worker is done, then sending the worker to its job again?

Right now, you'd need to do something like this:

. "This is the control robot"
: "dowork"
. "Something here"
: "tryworker"
wait for 1
if "w_busy" > 0 then "tryworker"
send "worker" to "increment"
wait for 1
goto "dowork"
end

Worker:

set "w_busy" to 0
end
: "increment"
set "w_busy" to 1
lockself
inc "important_counter" by 1
unlockself
set "w_busy" to 0
end

My suggestion would turn that code into this, sparing a counter and a few lines of code, for readability (making it more humanly comprehensible):

. "This is the control robot"
: "dowork"
. "Something here"
: "tryworker"
wait for 1
send "worker" to "increment" else "tryworker"
wait for 1
goto "dowork"
end

end
: "increment"
lockself
inc "important_counter" by 1
unlockself
end

I get that it might not be that important of a change in the long run, but I thought it might be useful to more people out there. In fact, if anyone has suggested this before, I apologize, but the search function didn't appear to be working so I could not check for that.

only partially related, but if you set "commands" really high mzx turns into a cooperative multitasking environment and then you don't need these fake mutexes. mzx is not a real multithreading environment so you don't need real synchronisation primitives.

1) Internally, your suggestion indistinguishable from SEND # # "label".

2) It's unnecessary.

...
set "worked" 0
: "l"
send "worker" "work"
wait 1
if "worked" = 0 "l"
...

end
: "work"
inc "worked" 1
end

Lachesis, on 11 March 2014 - 05:44 PM, said:

Sure, I understand you could do it like that, but the purpose of this hypothetical SEND would be to remove the need to waste a counter. Also, I would prefer the implementation I suggested in my original post over the one you posted here, since your implemention could end up in an infinite loop (worker doesn't lock itself, if the operation that the worker is supposed to do is not atomic and lasts for longer than 1 cycle, the controller will try to send the worker to the "work" label agan (because "worked" hasn't been increased yet). No work gets done and they both get stuck in a loop. My implementation both includes the "mutex" part and the "make sure work gets done and not ignored" part.

Lancer-X, on 11 March 2014 - 11:50 AM, said:

Maybe the fact that I don't know the intricate details of MZX's implementation is to blame here, but, the way I see it, doing repetitive tasks the way I showed in the OP is at least marginally more efficient than using a subroutine (as follows):

: "dowork"
. "Something here"
goto "#increment"
wait for 1
goto "dowork"
end
: "#increment"
inc "important_counter" by 1
goto #return
end

Am I correct? Or are they effectively the same in terms of execution speed?

Setting commands really high has the old issue of possibly bringing MZX to a crawl if you remove 'wait 1's to "force" such tasks to be atomic. In case you use wait 1's, they aren't atomic anymore, and if you split them across robots you'd end up in the same situation I showed. Basically, the way I see it, the moment an operation in robotic takes longer than a cycle, it's not atomic and if you use the "pseudo-threads" implementation you'll need to "mutex" it. The counter increasing example I showed was possibly not the best... but I think you get the point. If you use a robot as, for example, a "flusher" robot that "flushes" the content of the vlayer to the overlay everytime another robot changes the vlayer and requests a "flush", that operation would likely take more than a cycle to complete, assuming you don't have a fast PC that can withstand MZX running on high 'commands' settings with no 'wait 1's (or you want to design your game with players with old PCs in mind).


Anyways, if the Robotic interpreter itself doesn't support this command, as Lachesis mentioned, it's no use arguing anymore. One counter isn't really a burden anyways, and really it just becomes a question of space optimization vs. speed optimization (space - no counter, might slow down MZX if you force high 'commands' with no wait 1's; speed - makes speed more stable by adding wait 1's, requires one extra counter for each worker you add).

This post has been edited by Why-Fi: 11 March 2014 - 08:35 PM

The space in memory a counter takes up is essentially negligible and cluttering the counter namespace isn't a performance concern because MZX has used hash tables for counters and strings since 2.84c's release (even before, it took millions of counters to make a difference and the primary performance hit was to counter creation, not lookup).

Fair enough. I did forget about the counter hash-table storage since 2.84c. Maybe I should research a bit about MZX's internal workings before I make similar suggestions.

Updating status to: Rejected

Moving to: Rejected Requests