At 11:59 PM -0500 1/3/04, Gordon Henriksen wrote:On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed automatically by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise. Shouldn't even be pursued.
Erm... that turns out not to be the case. A lot. (Yeah, I know, I said I wasn't paying attention)
An interpreter *must* lock any shared data structure, including PMCs, when accessing them. Otherwise they may be in an inconsistent state when being accessed, which will lead to data corruption or process crashing, which is unacceptable.
These locks do not have to correspond to HLL-level locks, though it'd be a reasonable argument that they share the same mutex.
Process crashing unacceptable? Absolutely. Complete agreement.
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'm not okay with parrot crashing for any reason, ever, though, so where locking is not provided, PMC classes *must* be coded *very* carefully so as to avoid crashes.
—
Gordon Henriksen [EMAIL PROTECTED]
