No problem here. I repeated the 'repeat loop 3 times.
$ lsb_release -a
[...]
Description: Ubuntu 9.10
Release: 9.10
Codename: karmic
$ mzscheme -v
Welcome to MzScheme v4.2.1 [3m], Copyright (c) 2004-2009 PLT Scheme Inc.
But bugs related to atomicity exist anyway, this is certain. The thread/atomicity stuff is a subtle mess.
Threads are never a solution. Message-passing / shared-nothing threads maybe, event-based maybe, something else maybe. But traditional "à la Java" threads have prouved to be a bad idea.
Why are threads in Arc, after all? For srv.arc. Which would do better w/ an event-based architecture.
And the GIL. Gosh. Python is learning the hard way how a GIL is painful and should probably be avoided from the start.
BTW:
arc> (= var 0 tbl (obj var 0))
#hash((var . 0))
arc> (repeat 50000 (thread (++ var) (++ tbl!var)))
nil
arc> var
50000
arc> tbl!var
50000
; OK, the above is normal and expected
; Now, let's sleep for a random time in each thread before to '++
arc> (= var 0 tbl (obj var 0))
#hash((var . 0))
arc> (repeat 50000 (thread (sleep:/ (rand 40) (inc:rand 50)) (++ var) (++ tbl!var)))
nil
arc> var
49817
arc> tbl!var
50047
; WTF?!
Huh I'm surprised, I knew 'assign wasn't atomic, but I thought it was OK for 'sref ('++ expands to '= which expands to a call to 'sref but in a 'atwith expression). Seems not. Is my test bogus somehow?
----
Some people, when confronted with a problem, think "I know, I will use threads." Now they have two problems.
(Running on the Ubuntu/MzScheme combo described in previous comment, and on plain vanilla Arc 3.1 (ycombinator.com/arc/arc3.1.tar). Runned ~10 times, each time the results are different but never 50000)
Yes, reproduced on ubuntu/mz4.2.4 (sorry I was making stupid mistakes last night when I tried it out). On snow leopard/mz4.2.2 the tbl!var is always at 50k, but the global var is always lower. I've seen it as low as 43866.