No, you haven't. What you've implemented is a pale imitation of the
ants simulation that neglects its most important features.
It doesn't come close to doing the same job.
The ants simulation was designed to show how to do things that are
difficult to do without an STM. It is not simply a demo of how to use
multiple threads to make ants move around on screen.
STM lets you make decisions based upon consistent information. So,
e.g. in the Clojure version when the ant looks around and sees food on
an empty space, and makes a decision to pick it up, it will be able to
do so without finding it missing or the space occupied, i.e. it will
atomically be able to make a decision and act upon it, even one
involving multiple ad hoc elements. In your code you've made it so the
ants can't see each other, thus removing the coordination problem
rather than solving it. The Clojure code can handle arbitrary sets of
read/modify operations, on arbitrary sets of involved data,
consistently.
You use timeouts on your locks, and silently fail to do the requested
operation if the lock times out. But the caller of move expects it to
work - it's not called maybe-move-if-we-can-get-the-lock. What if
evaporate did something important? It wouldn't be ok for it to skip
some steps if it can't get the locks.
There's more. You hold locks on an ongoing basis, vs obtaining and
releasing in a scope - always tricky and dangerous. Do you know how
that will behave should those locks map to OS resources? How might non-
scoped locks thwart optimization? In move, you obtain the new lock, do
some work, then unlock the old, and right now that work might be
trivial. But what happens when someone comes along later and makes the
work something that can fail? You risk orphaning a lock on such
failure. You simply cannot use locks without proper error handling.
The Clojure ants sim also tackled the 'reporting' problem. How can you
get a consistent view of a world with many concurrent updates without
stopping it? The Clojure render function works with a consistent
snapshot of the world. There's no chance of it drawing the same ant
twice, or two ants in the same place. You've taken all the challenge
out of it by removing correlated data. Still, your code can show a
view of the world that never existed. You might think it's no big deal
when you are just painting in a game-like sim, but the techniques in
the Clojure version work in serious situations when related things
need to add up, and yours simply won't.
In short, your version doesn't compare whatsoever to what the Clojure
version provides. By making the problem simpler you've destroyed its
purpose, and you've avoided the illustrative challenges.
The purpose of the ants sim was to demonstrate techniques for handling
multithreaded applications where units of work involve consistent,
arbitrary, overlapping subsets of information, and, reporting
consistently on correlated data subject to concurrent modifications.
The Clojure version demonstrates that and your version does not.
Rich