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

Jump to content

Report ID 607 Title send "robot" else "label"
Product Rejected Requests Status Rejected (Severity 0 - None Assigned)
Version - Fixed in -

Page 1 of 1
  • Cannot start a new Issue
  • Closed Issue This issue is locked

Report ID #607: send "robot" else "label"

#1 User is offline  
Why-Fi 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 336
  • Joined: 21-October 07
  • Gender:Male
  • Location:Portugal

Posted 10 March 2014 - 10:03 PM

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.
Posted Image


Page 1 of 1  
  • Cannot start a new Issue
  • Closed Issue This issue is locked

Replies (1 - 7)

#2 User is offline  
Dr Lancer-X 

  • 電波、届いた?
  • Group: DigiStaff
  • Posts: 8,938
  • Joined: 20-March 02
  • Location:ur mom nmiaow

Posted 11 March 2014 - 11:50 AM

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.
Posted Image
<Malwyn> Yes, yes. Don't worry I'd rather masturbate with broken glass than ask you for help again. :(

#3 User is offline  
Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 11 March 2014 - 05:44 PM

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

"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository

#4 User is offline  
Why-Fi 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 336
  • Joined: 21-October 07
  • Gender:Male
  • Location:Portugal

Posted 11 March 2014 - 08:33 PM

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

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



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:

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.


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

Posted Image

#5 User is offline  
Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 13 March 2014 - 02:42 AM

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).
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository

#6 User is offline  
Why-Fi 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 336
  • Joined: 21-October 07
  • Gender:Male
  • Location:Portugal

Posted 13 March 2014 - 07:39 PM

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.
Posted Image

#7 User is offline  
Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 22 March 2015 - 04:57 AM

Updating status to: Rejected
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository

#8 User is offline  
Terryn 

  • ******
  • Group: DigiStaff
  • Posts: 2,961
  • Joined: 12-October 00
  • Gender:Male

Posted 23 March 2015 - 06:08 PM

Moving to: Rejected Requests


Page 1 of 1
  • Cannot start a new Issue
  • Closed Issue This issue is locked

1 User(s) are reading this issue
1 Guests and 0 Anonymous Users


Powered by IP.Tracker 1.3.2 © 2024  IPS, Inc.