An idea on multithreading implementation

Jan Schenkel janschenkel at yahoo.com
Tue Jan 25 01:22:10 EST 2011


--- On Tue, 1/18/11, Bob Sneidar <bobs at twft.com> wrote:
> Hey I had a great idea on how to
> implement multithreading without jacking up anyone's legacy
> code. Have LiveCode work along a single thread as usual, but
> add the keywords "in new thread" to the do command or open
> stack command. That way someone could invoke a new threaded
> process, or launch a stack in a new thread etc if they
> wanted, but not hose anything someone had already written.
> You could launch a progress bar that you could monitor the
> state of an operation and provide real feedback for
> instance, without having to poke your head out of a running
> command from time to time. 
> 
> Any thoughts?
> 
> Bob
> 

The problem of multi-threading is not executing multiple blocks of code simultaneously, it's management the concurrent access to state, and in particular to shared, mutable state, that's the trick. If your new thread were to work in complete isolation, not sharing script-local variables or any control properties, there would be no issue. But that would be an extremely limiting environment to work in.

Suppose the RunRev team makes container access thread-safe, so:
- put x into y
- put "Smurf" after field "Figurines"
- add 9 to line 3 of field "Numbers"
- ...
would protect the 'target' of the operation, you're still faced with race conditions. Take a script as simple as this:
##
answer field 1 & field 1
if field 2 < 9 then
  answer field 2 && "is less than 9. Destroying civilization now..."
end if
##
Think it through, and you'll see multiple potential issues:
- on the first line, there could be a change to the field content in between the two reads of the text of the field
- similarly, in between checking the text of field 2 in the if statement, and showing it in the answer box, it could very well have changed

The only solution is to add complexity to the language to allow locking and 'synchronization" (in Java parlance) to protect resources during the execution of certain code blocks. And even then, you can never be quite sure what the hardware will do, as it tries to optimize behind your back - in fact, these days a short-circuit AND operation can be slower than the variant which first evaluates both operators and then applies the operator.
A very interesting read in this regard, is the presentation "Not Your Father's Von Neumann Machine" by Java concurrency gurus Dr. Cliff Click and
Brian Goetz, which explains how times have changed:
<http://developers.sun.com/learning/javaoneonline/sessions/2009/pdf/TS-5496.pdf>

What the LiveCode does offer in terms of multi-threading, is socket communication with callback methods: accept, read and write can happen on separate threads and when the work is done, your control receives a message so that it can take the logical next step. No two such messages are processed at the same time.
This is an easy system to reason in, and performs quite well, as long as we keep the 'unit of work' small, a LiveCode server socket aplication is a very good workhorse and responsive to sizeable group of users. Frankly, I wish they'd extend the callback mechanism to file, process and database read/write operations, before implementing full multi-threading.

Jan Schenkel.
=====
Quartam Reports & PDF Library for LiveCode
www.quartam.com

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)



      




More information about the use-livecode mailing list