lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 16 Mar 2007, at 15:57, Rici Lake wrote:

Johann Hibschman wrote:
Rici Lake wrote:
The coroutine mechanism is not implemented with threads, although the API calls them threads (which they are, but not OS threads); Lua threads are exposed as instances of a Lua_State, and those Lua_States are related to each other. You probably don't want to run those simultaneously in different OS threads, but it is theoretically possible; the language does not provide any synchronization primitives, though, so you need to implement your own so that related Lua_States don't trod on each other's globals.

I keep wondering about this; wouldn't the garbage collector require some synchronization, in order to avoid trouble with multiple Lua-threads running in multiple OS-threads?

Yes, and Lua does that (if you configure it to).

There are macros lua_lock() and lua_unlock() which are supposed to acquire and release a mutex (or something equivalent). Lua ensures
that the mutex is held during the execution of any Lua API function,
and during the execution of the Lua VM. While the VM is running, the
lock is periodically released in order to allow other related states
to run. During a garbage collection action, the lock is held.

To follow up on what Rici said, we did this in an early version of Lightroom (way before the public betas) and we found that we were spending a ridiculous amount of time in the OS lock/unlock primitives.

Our current approach involves using multiple separate Lua "universes" with some supporting code to copy certain data types from one universe to another. Though cumbersome, this avoids the bulk of the OS overhead.

We're currently experimenting with a variation on "occasional threading" described by Russ Cox (http://lua-users.org/lists/lua-l/ 2006-11/msg00368.html), and though we're not using it yet, this coarse-grained locking seems to be more fitting to our needs.

-Eric