[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [PATCH] Proposal: asynchronous coroutines and multithreading
- From: mniip <14@...>
- Date: Sun, 04 Jan 2015 16:45:28 +0300
> Per-state mutexes will be quite tricky to implement, as you don't really have
> per-state variables. You can have a reference to the same table in two
> coroutines. You can even have access to the same local numeric value from two or
> more coroutines if you pass a function around that have it as an upvalue.
> One way to implement per-state mutexes is for every TValue to have an "owner"
> state, so you lock that state mutex before dealing with the value. This will
> probably require huge efforts and will increase size of TValue, which is not
> good (OK, on 64bit architectures, you can squeeze in 32bit index without size
> penalty as TValue is being padded to 16 bytes anyway, that is in Lua 5.2).
Yeah I'm rethinking it right now, they won't be per-state mutexes but per-object
mutexes. But you don't have to lock TValues at all! You only have to lock
GCObjects. The only case, I think, where 2 states may simultaneously access the
same TValue is tables, but at that point it's easier to just lock the whole
table (which is a GCObject by the way).
/* mniip */