Reinventing wheels?

Jump to navigation Jump to search
Revision as of 2 March 2019 at 01:27.
The highlighted comment was created in this revision.

Reinventing wheels?

Although the sample code implemented tick synchronization between worker thread and robot thread, the use of token may not be necessary, since Java already had similar mechanism.

    worker = new Thread(() -> {
      try {
        while (true) {
          Thread.sleep(1000);
        }
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
      }
    });

call worker.interrupt() whenever you don't need it anymore, or just wait robocode to call that method for you.

    Xor (talk)08:21, 28 February 2019

    It's more likely a sign of the state of Java (or the author's knowledge of it) at the time the page was drafted. It looks like the original is over 10 years old.

    Besides Toad, do any bots actually make use of multithreading? I've always felt the community considered it to be a "dirty" tactic.

      Enamel 32 (talk)04:42, 1 March 2019

      I'd be in favour of disabling multi-threading in the rumble, or somehow only allowing a single thread to run at the same time. Otherwise there could be some very dirty tactics like starving the opponent of CPU or memory bandwidth during their turns, which is against the spirit of trying to keep the bots' processing isolated except through the robocode engine.

        Skilgannon (talk)22:52, 1 March 2019

        I agree that computational tasks should not be allowed to run multithreaded in rumble or even in general robocode, or at least we should not allow threads to be run when other bots are running.

        However as long as you do file I/O for data logging purposes, multithreading is essential as it’s not fair for your main threads to run blocking I/O only to get a lot skipped turns.

        Anyway, a better solution is to provide this in robocode, so fairness is guaranteed.

          Xor (talk)02:27, 2 March 2019