In the end, all languages lacking of PV but offering UpVal end up with the GIL, which only nominally claims the native thread is being taken advantage of. Lua avoids that thing for much good, in my opinion.
On Sat Jan 03 2015 at 6:19:11 AM Javier Guerra Giraldez <
javier@guerrag.com> wrote:
On Sat, Jan 3, 2015 at 2:06 AM, mniip <14@mniip.com> wrote:
> All of this is built with pthreads, using python-style Global Interpreter Lock
> (lua_lock and lua_unlock helped a lot in the process).
There was a similar patch for Lua 5.0 or 5.1, ThreadLua, i think. It
was nice and easy to use, but realistic benchmarks showed not only
that there was no real concurrency while executing Lua code (as
expected from the use of a global lock), but also that the constant
locink/unlocking was terrible for performance. the more cores you
used the worse it was, easily spending over 50% of time just on the
lock.
The nice thing was to use it for IO, you could easily spawn a thread
to fetch something from the network and process it. But when thinking
about almost any reasonable use, it was evident that message passing
fits better.
For a while i tried to do real concurrency in Lua, first by attaching
a lock to each table (big nightmare, easy deadlocks), and then by
replacing tables with lockless structures (hard to get the semantics
just right, not so faster than locks).
In the end, message passing is just so much easier...
still, i think that a language designed from the start for concurrency
would need serious help from escape analysis and other compiler tools
to reduce the need for sync primitives (either locks or CAS)
--
Javier
