> In this particular case, the STM system is more important than the
> fact that it uses persistent data structures. A Java solution that
> didn't have persistent data structures but still had an equivalent STM
> could use copy-on-write: it would certainly be slower, but I think it
> would work just fine (the data structures are quite small).
If the DS are small then using j.u.cconcurrent.CopyOnWriteArrayList
may be an option, but since the program is fairly write intensive this
would be a lot of overhead.
Since the data structures are small you could have a timer or similar
(this would also allow you to set a target frame rate) that takes
snapshots of the state and uses that to update the UI. Something like
this:
final ExecutorService drawService = Executors.newSingleThreadExecutor
();
Runnable drawTask = new Runnable() {
private List stateSnapshot;
public void run() {
if (stateSnapshot == null) {
assert !EventQueue.isDispatchThread();
acquireGlobalLock();
stateSnapshot = copyStateOfTheWorld(world);
releaseGlobalLock();
EventQueue.invokeLater(this);
} else {
assert EventQueue.isDispatchThread();
updateUI();
stateSnapshot = null;
drawService.submit(this);
}
}
};
> In fact, I think a neat demonstration for your talk would be to start
> with a naive Java solution with a global lock. Then introduce a read-
> write lock. Then stripe it in say 4 locks, then 8, then one for each
Something that discusses a few different approaches in Java before
moving on the the Clojure version would make for a pretty interesting
talk I think.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
