There's a cool quote in the paper The Evoloution of Lua (Section 5.4) that says...
"Second, and more important, we did
not (and still do not) believe in the standard multithreading model,
which is preemptive concurrency with shared memory: we still
think that no one can write correct programs in a language where
‘a=a+1’ is not deterministic."
It certainly makes it blimmin difficult to write correct software.
For those who don't know Lua, its a great scripting language that's a good balance between scheme/lisp/ruby etc. Its easy to embed into an application (in fact a number of games use it), its fast, it's simple, nice syntax, and powerful. www.lua.org . One of the interesting thing about Lua is that it doesn't have native support for OO (in the way C++ / Java / C# / Ruby) do. But because of its meta programming approach you can add OO constructs. You can define what a "class" is and how "inheritance" works. Which is more lisp like. This approach is quite good, as it means it's a "multi paradigm" type language, where you can program "functional" or "OO" or mix it all up, create DSLs, or whatever. The disadvantage is that you can end up with a bunch of different approaches that don't mix well.
Subscribe to:
Post Comments (Atom)
6 comments:
"...we still
think that no one can write correct programs in a language where
‘a=a+1’ is not deterministic."
I could not disagree more with that statement. Preemptive multithreading has many applications that cannot be completely replaced with coroutines without too much hassle. And saying that with PMT you end up only with undeterministic programs just shows a lack of understanding of synchronization and how to use it correctly.
Although I must say that the whole point of PMT is to remove from the programmer the task of scheduling. The CPU is much much better at scheduling than a human will ever be. Programmer-scheduled apps are highly inefficient due to the programmer's natural inability to foresee CPU time consumption. Unless the programmer wastes hours calculating how many millisecond a certain operation will take he will be unable to predict when to suspend a thread with low priority.
Either he ends up with a thread that abuses the CPU or one that never finishes what it was supposed to do.
Some things cannot be done at all with Lua's cooperative multithreading.
Suppose I want to do something interactive in a GUI while I'm loading data from a file.
The file operation blocks and... so do every other coroutine, because Lua is single-threaded.
Anonymous: Lua has tools to handle this issue. In fact, almost the exact problem you brought up was handled in the book.
The general answer is pretty simple, have your file access / socket reading / etc functions yield for you until the data is available.
Lua also supports multithreading very well compared to other scripting languages like Python or Ruby, by allowing you to create multiple instances of the VM/interpreter -- one per thread -- without requiring any global locks of any kind.
You can then implement a message passing interface between the different interpreters.
I just started looking at Lua last week, and I am surprised that it doesn't have multithreading, as its authors don't believe in multithreading. Their coroutines approach is too cumbersome.
for this reason, I am not going further with Lua as I use a lot of multithreading in my Java programs, and so far has never had any problem with any of the programs that i write. I am going next to try Ruby, it seems to have both multithreading and some coroutines.
This article might be 3 years old, but it still seems to pop up in a Google search. The better way to do this is through mutex, both explicit and through Lua's lock support:
Threads Tutorial
http://lua-users.org/wiki/ThreadsTutorial
Coroutines are not preemptive multithreading, and locks are always needed when data (the Lua state) is shared between threads.
Post a Comment