[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [PATCH] Proposal: asynchronous coroutines and multithreading
- From: Dong Feng <middle.fengdong@...>
- Date: Sat, 03 Jan 2015 18:20:51 +0000
I feel it is fundamentally flawed to use data-sharing preemptive threads in a language where no explicit PV-operation is exposed. And even the PV-operation were indeed exposed, it would have been extremely difficult to use in an environment where provide closure present, and where every function is a first-class value that is accessed through UpVal or table field or names of other sharable types.
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 <email@example.com
On Sat, Jan 3, 2015 at 2:06 AM, mniip <firstname.lastname@example.org> 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
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
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)