Data corruption unacceptable? I disagree. It depends on the contract put forward by the language in question. Notably, Perl makes no such guarantees thus far, being as how it doesn't (any longer) run in a traditional threaded model. Successfully threaded languages and virtual machines explicitly make NO such guarantees. I'm completely okay with the potential for inconsistent data where the user doesn't take precautions. If the alternative is my code bogging down to half of its ideal speed because parrot is wasting time: acquiring three mutexes with deadlock detection so that it can execute add $P10, $P11, $P12; acquiring a mutex every time it indexes a string register; acquiring a mutex so it can examine cache->int_val-if those are the alternatives, I'm for the potential for inconsistent data. (And I say wasting because it's completely unnecessary in a good 99% of cases; the vast majority of data is not shared between threads at all.)
I agree with most what is said here.
However, I think there should be some type of debugging mode that _would_ do all of the locking and deadlock detection (and whatever other debugging capabilities we can think of). Occasional, hard-to-reproduce data corruption is the single most problematic thing to debug in threaded applications. It allows you to create Heisenbugs that will only show up under specific load conditions and/or specific platforms. And when that happens, it doesn't matter that your threaded application doesn't crash: for the users it does the equivalent, namely produce the wrong results occasionally, and therefore not production ready.
Liz
