[Shootout-list] Re: Integer overflow

[Brent Fulgham]

--- Bengt Kleberg wrote:
> languages that relegate threads to second class
> citizenship (by only allowing few of them, or by 
> making themimpractically slow) should come 
> out worse in a good threads creation test. so i
> favour a test with many threads.

This is a valid point.

> if at all possible i would insist upon porcesses,
> but that becomes hard to test.

One possible way would be to provide some kind of
global state that threads would tend to "share", while
separate processes would obviously safely protect. 
Perhaps some kind of global variable that each process
increments.  If the variable is protected, it would
increment N times (where N was the number of loops in
the code or whatnot).  If it were unprotected, it
would update N*M times, where M was the number of
threads.

Languages that found processes too expensive could of
course use threads, but they would have to protect the
global variable with mutexes or similar to enforce
update privilidges.

The two are largely consistent in meaning, but
thread-based solutions would require more boilerplate
coding to enforce access protection, while
process-based languages would get that for "free".

This is not unfair; or, at least it is no more unfair
than Erlang, Clean, or Scheme competing in the Object
Instantiation test.  :-)

-Brent