*) MUTEX - this is a low level, under the hood, not exposed to users, thing that can be locked. They're non-recursive, non-read/write, exclusive things. When a thread gets a mutex, any other attempt to get that mutex will block until the owning thread releases the mutex. The platform-native lock construct will be used for this.
*) LOCK - This is an exposed-to-HLL-code thing that can be locked. Only PMCs can be locked, and the lock may or may not be recursive or read/write.
*) CONDITION VARIABLE - the "sleep until something pings me" construct. Useful for queue construction, always associated with a MUTEX.
*) RENDEZVOUS POINT - A HLL version of a condition variable. *not* associated with a lock -- these are standalone.
Note that the mutex/condition association's a POSIX limitation, and POSIX threads is what we have on some platforms. If you want to propose abstracting it away, go for it. The separation doesn't buy us anything, though it's useful in other circumstances.
*) INTERPRETER - those bits of the Parrot_Interp structure that are absolutely required to be thread-specific. This includes the current register sets and stack pointers, as well as security context information. Basically if a continuation captures it, it's the interpreter.
*) INTERPRETER ENVIRONMENT - Those bits of the Parrot_Interp structure that aren't required to be thread-specific (though I'm not sure there are any) *PLUS* anything pointed to that doesn't have to be thread-specific.
The environment includes the global namespaces, pads, stack chunks, memory allocation regions, arenas, and whatnots. Just because the pointer to the current pad is thread-specific doesn't mean the pad *itself* has to be. It can be shared.
*) INDEPENDENT THREAD - A thread that has no contact *AT ALL* with the internal data of any other thread in the current process. Independent threads need no synchronization for anything other than what few global things we have. And the fewer the better, though alas we can't have none at all.
Note that independent threads may still communicate back and forth by passing either atomic things (ints, floats, and pointers) or static buffers that can become the property of the destination thread.
*) SHARED THREAD - A thread that's part of a group of threads sharing a common interpreter environment.
Anyway, there's some terminology. It doesn't solve the design problem, but hopefully it'll help everyone talk the same language.
Remember that everything from the wrapped OS interface on up is up for grabs -- while we're not going to build our own mutexes or thread scheduler, everything that's been implemented or designed to date can be changed with sufficient good reason. (Though, again, the more you want to change the more spectacular the design has to be)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
