Zugg Software :: View topic - New CMUD Feature: Sequential Scripting Threads!

Posted: Sat Jul 07, 2007 3:52 am

OK, looks like I'm past my headaches. The thread system is working well now. I've got the #WAITTHREAD working and have tested two triggers going back and forth. Here is my test:

Wizard Joined: 17 Jun 2006 Posts: 1201

Very nice. I've always wanted something like #waitfor. I'm looking forward to it.

Posted: Sat Jul 07, 2007 6:13 am

If there is a possibility of deadlocks in scripting threads, is it possible to add the ability for CMud to display existing threads? Basically a list that shows all the running script threads, from which the user could select individual threads to kill manually if needed. If it's possible to track what any given thread is waiting for, you could even add a check for dead-locks (maybe only run on user request, or infrequently if it takes a lot of time to run) so that the user doesn't have to eyeball the list to pick out which threads are waiting on each other -- tricky if there are more than two in the circle.

I don't know if this is feasible or not, but I thought I'd throw the idea out there. (I bet it'd be useful during the development of complicated scripts too.)

Posted: Sat Jul 07, 2007 9:43 pm

So I read your test and I can finally agree with the output!!

I think my brain is finally giving up on me because it took me about 10 minutes to sort out what is happening in that test.

The tricky bit is trying to figure out exactly what is being processed at the point that #show "thread2" happens because at that point thread1 is still running and is going to continue to run until it gets suspended. It makes you wonder for a while why "back in 1" doesn't show up before "begin 2".

Posted: Sat Jul 07, 2007 10:14 pm

It'd be nice if that example could be given with the #waitthread command in the help. While it takes a fair bit of head-bending to understand, it's a very good example of how #waitthread works. I can't think of a simpler way to explain it.

Apprentice Joined: 06 Apr 2004 Posts: 173

instead of making regex vs non regex why not think more general than you are thinging of and do something like this instead:

#WAITFOR @function_result()

where function_result is a function.

inside of @function_result you could test %line, against the %regex() or %match() expression of your choice.

Once the expression returns true it returns.

EDIT: {} could in this case refer to the "default" function of %match(%line,"whatever you typed")

so that #WAITFOR {blah} will be the same as: #WAITFOR @function()
#FUNCTION function {
%match(%line, blah)
}

Newbie Joined: 03 Jan 2006 Posts: 9

What great news! Zugg, this is an addition to CMUD that can potentially sell copies. Up until now I've not had much interest in changing from ZMUD to CMUD but this feature has changed my mind.

Posted: Sun Jul 08, 2007 10:30 pm

You're going to have to do so much updating to the CMUD section of the website for 2.0, Zugg... so many new features! Twisted Evil

Adept Joined: 04 Feb 2005 Posts: 246

As I look this over... these are not multiprocessing threads, but more like co-routines? In other words, only one thread is ever running in the CMUD interpreter, and only stops running if it ends or gets suspended?

Posted: Mon Jul 09, 2007 7:03 am

Sort of. Signals can make threads run simultaneously, but that's all.

Posted: Mon Jul 09, 2007 1:06 pm

Posted: Mon Jul 09, 2007 6:53 pm

Adept Joined: 04 Feb 2005 Posts: 246

If there is true concurrency, then without a mutex or at least an atomic test and set operator, I don't think you can develop a reliable thread synchronization method from user code, which makes modifying non-local variables iffy at best...

Posted: Tue Jul 10, 2007 12:23 am

Zhiroc: You can speculate all you want, but there *is* true concurrency and you don't need mutex in your CMUD scripting code. CMUD is handling that internally for you. All accesses to the user interface and the underlying database are synchronized via critical sections. That's the whole point of developing CMUD so that it's threadsafe. I've written two threads that access the same non-local variable, and it works fine. Of course, if both threads *store* different values to the same variable, then the value of that variable is undefined since you don't know which thread will save the final value. But it doesn't crash or anything like that because the database access is synched properly.

Yes, this was tricky code to write, but you make it sound like it should be impossible, and it's far from impossible. It just takes some careful coding.

Adept Joined: 04 Feb 2005 Posts: 246

Posted: Tue Jul 10, 2007 6:21 am

Well, stuff to think about for the future, but I'm not going to worry about it right now. If people start relying upon setting the same data variable from multiple threads, then they deserve these headaches. You *can* do it with the #WAITTHREAD method, because that effectively puts one thread to sleep, while the other thread writes to the variable. See the example I gave above for #WAITTHREAD...each of these threads could write to the same variable without trouble, because they are not running concurrently. They are using #WAITTHREAD to synchronize and ensure that only one accesses the data at once, which is really the same thing that would happen with any sort of lock or sync command.

The main purpose of the multithreading in v2.0 was to allow sequential scripts using #WAITFOR, and to allow the #WAIT command to finally work. Getting into true synchronized threading that allows multiple threads to write to the same variables is beyond the scope of this update.

Posted: Tue Jul 10, 2007 6:14 pm

Actually, after thinking about this more overnight, I think Zhiroc is correct and I need to add a simple "critical section" method. Instead of using #SYNC, and staying away from the Mutex term (I think that term gives people headaches :), I decided to name it #SECTION:

#SECTION name {code}

The idea is that this creates a "named section", and if you have more than one section with the same name, only one will execute at a time. Essentially, this is a critical section. By using a "name" instead of tying it to a specific variable, it allows you to name your sections however you want. You can name them for the variable that you are changing, or anything else.

This is currently just a quick and simple way to avoid problems with multiple threads that write to the same variables. It uses the existing RTL_CRITICAL_SECTION features in the Windows API, so it was easy to add and should work pretty well.

Adept Joined: 04 Feb 2005 Posts: 246

Cool. One question is whether the name uses the package/module/class namespace or is just a string. It might not be critical Smile

but it might be nice if packages that might be written by others could isolate themselves from another using the same names.

Posted: Tue Jul 10, 2007 7:54 pm

Nope, it's a global namespace. This is because you might actually want to protect code across packages. If a package designer wants something that just works within the package, then I'd suggest using a naming scheme, such as PackageName_SectionName or something like that.

Posted: Tue Jul 10, 2007 8:41 pm

Btw, here is another set of examples that show how #SECTION can be useful. Remember in the above example we saw that "thread2" got executed immediately (the "begin 2" happened as soon as "thread2" was displayed). With a #SECTION you have a bit more control over this. Consider the following example:

Without sections:

Adept Joined: 04 Feb 2005 Posts: 246

Life's never simple... just thought of a complication you'll have to deal with: nested #SECTIONs.

If they are allowed, then it might be that two #SECTIONs for the same name nest (usually because of something like two aliases, and one calling another, not because the user actually wrote it that way intentionally). If you don't handle this with reference counts or the like, then the nested one will block forever. Also, nesting is a bit tricky for users, since they have to obey a locking order. If one thread does: #SECTION a { #SECTION b {}} and another does #SECTION b { #SECTION a {}}, they will at some point deadlock.

If you don't allow it, then the error behavior has to be defined, and this could cause scripts to fail unexpectedly (especially if the name that was used by more than one package by coincidence).

It might be nice to have the name be optional, and that would mean some global, unnamed #SECTION.

And finally, I guess that a #SECTION would act like a #WAIT in that it will (or might) allow other threads to run? So would exectuting one in a trigger always allow the next input line to be triggered on by another thread, or only if the #SECTION blocks?

Posted: Tue Jul 10, 2007 11:32 pm

The Critical section support in Windows already takes care of this. It has a reference count for the number of times a section is entered within the same thread. As long as there is the same number of EnterSection and LeaveSection calls, then there isn't any problem. A thread cannot deadlock itself with this. Take a look at:

http://msdn.microsoft.com/msdnmag/issues/03/12/CriticalSections/default.aspx

for more information on how the RTL_CRITICAL_SECTION works in Windows.

Yes, users need to be careful when nesting in different locking orders. But this isn't anything I can worry about. Anyone playing with threads and synchronization always has to worry about this kind of stuff, no matter what programming language you are using.

I thought about making the name optional, but I think that leads to lazy programming. I want people using sections to *think* about what they are doing.

And finally, yes, a #section acts like a #wait in some cases. If the thread is suspended because it's waiting on the lock, then other threads can run. But this only happens if the thread gets suspended. If there isn't any lock, then execution proceeds as if the section was not there.

Posted: Wed Jul 11, 2007 3:58 pm

Tarn: I think that's what we already been talking about...you *can* have multiple threads running at the same time. In the above example, the triggers "test1" and "test2" are running at the same time, which is why sometimes you get "end of 1" before "end of 2", and sometimes you get "end of 2" before "end of 1". (Hmm, looks like Tarn deleted his post while I was replying ;)

In fact, I thought of something else last night...in all of the above examples, I have used "#SHOW whatever" to fire another trigger to get a second thread started. This is because triggers run in their own threads. But you don't want to use #SHOW just to start another thread...that's a kludge. You could use #FIRE or #RAISE to fire a trigger or raise an event, but what if you just wanted to run a particular Alias within a new thread?

So, I've extended the syntax of the #THREAD command a bit more. Here is the full syntax now:

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

I just want to point out that Lua supports co-routines, which are co-operative multi-tasking. Unlike native threads, a Lua function (which is running as a co-routine) can yield control back to its caller, giving you the ability to, effectively, pause a script in the middle.

There are advantages and disadvantages over pure threads - the advantage is that threads can actually be running "in the background" (assuming that is a good thing). The disadvantage with threads is that you need to worry about simultaneous access to variables, and then deadlocks if you start locking things. Real-life scripts (and not just examples) may soon need to explore the concept of the "deadly embrace" where two threads each lock a resource that the other one wants.

Co-routines avoid the deadly embrace problem, as they yield at known points. You can still make scripts that do things like display something and wait for a reply, with suitable use of co-routines and triggers which detect that a co-routine is running, and resume it at the appropriate point.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA