> Not sharing state means that Lua is reentrant. And it is reentrant, modulo bugs like the one under discussion. Thread-safety is a stronger guarantee that says that the code will avoid stepping on its own toes if two threads access the SAME state at the same time.
Some people believe otherwise. Wikipedia's page on reentracy has example that demonstrate that these two terms are not in a weaker/stronger relationship.
In my opinion, when we say that something is thread-safe, reentrant or not, this tends to be ambiguous unless we specify fully the expectations and the actual behaviour, as I hope I did in my original message.
Cheers,
V.
It's not my fault that practical computer programming doesn't use the vocabulary the same way that theoretical computer science does. Based purely on the formal definitions, all thread-safe code is necessarily reentrant -- if it weren't, it wouldn't be thread-safe.
The example of code that is thread-safe but not reentrant on Wikipedia is wrong. It's true that the code in the example is not reentrant, but I argue that it is also not actually thread-safe. Threads don't just refer to high-level operating system threads. They refer to any sort of multitasking, whether preemptive, cooperative, or true multiprocessing. Just because a system interrupt occurs in the same OS context doesn't mean it isn't concurrent execution; it's preemptive multitasking with some fairly specific requirements.
That said, because the vocabulary is used differently between those groups, you're right that it can be ambiguous, and you did indeed do a good job of specifying the expectations.
/s/ Adam
