 |
| Zugg |
Posted: Thu Jul 05, 2007 10:50 pm
New CMUD Feature: Sequential Scripting Threads! |
|
Zhiroc
Adept
Joined: 04 Feb 2005
Posts: 246
|
 Posted: Thu Jul 12, 2007 4:23 pm
|
That just gave me an idea.
We (those of us who have done MT programming) know just how hard avoiding race conditions is. #SECTION gives us the tool to avoid them, but let's face it, people are going to MT a lot, simply by the fact that they are going to use #WAIT and #WAITFOR without realizing the consequences. And after doing that, going through all your scripts to create critical sections around variable usage is something that is a) a royal pain; b) error prone, as the algorithms were probably not designed with MT in mind, and c) basically something that no novice programmer is going to consider.
So.... How about allowing a solitary #SECTION. No name, no code. What this means is that the thread suspends, and then at the next "opportunity", once again becomes the sole processing thread for the engine. That way, the only MT consideration you need to make is that global variable state can change across the #WAIT* and #SECTION.
Or maybe even better... Just have #WAIT* do this by default, and create a #RELEASE or something to actually let the current thread run in the background (it might still be useful to have the new #SECTION though). |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jul 12, 2007 6:13 pm
|
| Quote: |
| an unnamed block seems like a logical way to guarantee that nothing else is running |
I thought about that...it might be something that I can implement in the future. But it's very tricky to implement. If you increment a "master counter" at the beginning of each thread, and then decrement the count at the end of the thread, then you can tell how many other threads are running. You can then use this to test to see if you should suspend the current thread or not, and then wait until the count is zero to resume the thread. But the count won't ever hit zero because the suspended thread incremented the count at the beginning. So that means you need to decrement the count whenever a thread suspends, and increment it again when a thread resumes. But there are two many conditions here and it gets really easy to mess up and deadlock the system. I don't see how to use any of the current Windows mutex or semaphore systems to work in the way that is needed. If someone knows how to implement this, let me know.
| Quote: |
| So.... How about allowing a solitary #SECTION. No name, no code. What this means is that the thread suspends, and then at the next "opportunity", once again becomes the sole processing thread for the engine. |
That's an interesting idea. Again, I'm not sure how I'd implement this.
In general, I think I need to move on to other stuff right now. I think this is already a good start with threading and allowing basic sequential scripting.
The whole purpose of #WAIT and #WAITFOR was to allow simple scripts like this:
| Code: |
command 1
#WAIT 500
command 2 |
or
| Code: |
command 1
#WAITFOR pattern
command 2 |
These kind of examples do not need to worry about sections or threading. They just work as expected. I know the "power users" will probably try to do all sorts of other fancy stuff, and they are the ones who will need to worry about sections and other MT problems. But I have lots of other stuff to do in this version that I need to move on to. I can't spend a whole month trying to get the thread system perfect at this time. There will be plenty of time for that once people get their hands on this and start playing with it and reporting what real-life problems they are having. |
|
|
|
|
titus
Newbie
Joined: 12 Jul 2007
Posts: 4
|
Posted: Thu Jul 12, 2007 7:39 pm Re: New CMUD Feature: Sequential Scripting Threads!
|
| Zugg wrote: |
| I'm sure everyone wants me to release this right now, but I still have a lot more stuff to add to v2.0, so you'll just need to be patient for a few weeks. Try not to drool too much :) Between this new feature, the Lua support, and some of the other new stuff in v2.0, I'm hoping that this will finally give people some good reasons to switch from zMUD to CMUD. |
For what it is worth, I'll be buying cmud when v. 2.0 is released. Will that be soon? |
|
|
|
|
Zhiroc
Adept
Joined: 04 Feb 2005
Posts: 246
|
Posted: Thu Jul 12, 2007 8:08 pm
|
| Zugg wrote: |
The whole purpose of #WAIT and #WAITFOR was to allow simple scripts like this:
| Code: |
command 1
#WAIT 500
command 2 |
or
| Code: |
command 1
#WAITFOR pattern
command 2 |
These kind of examples do not need to worry about sections or threading. They just work as expected. |
Correct me if I'm wrong, but I thought that in both of those two cases, "command 2" gets run concurrently with other threads. So any global variable use after a #WAIT* might have to use critical sections to avoid race conditions. |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Thu Jul 12, 2007 8:40 pm Re: New CMUD Feature: Sequential Scripting Threads!
|
| titus wrote: |
| Will that be soon? |
End of the month is the current target. That's by no means definite, though. |
|
|
|
|
Vorax
Apprentice
Joined: 29 Jun 2001
Posts: 198
Location: USA
|
Posted: Fri Jul 13, 2007 12:40 am
|
Could there be an option added to the #WAITFOR command so that you could specify an amount of time to wait and argument to resume or abort the thread.
Abort would be the default argument.
Such as:
#WAITFOR {pattern} {500|abort}
If pattern isn't recieved within 500ms then it would abort the thread.
The above example and this one would be the same:
#WAITFOR {pattern} {500}
#WAITFOR {pattern} {500|resume}
That one would resume the thread if the pattern isn't recieved within 500ms.
Suspend wouldn't be a necessary option because by the use of #WAITFOR the thread is already suspended.
Just an idea to allow a little more control over thread execution. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 13, 2007 12:52 am
|
| Quote: |
| Correct me if I'm wrong, but I thought that in both of those two cases, "command 2" gets run concurrently with other threads. So any global variable use after a #WAIT* might have to use critical sections to avoid race conditions. |
Yes, "command 2" gets run concurrently with other threads. But if you are just sending a command to the Mud, it doesn't matter. As you said, it only matters if you start setting global variable values. And if you set global variables, then put it into a #section to protect it. I'm talking about the simple cases where the player is just trying to send a command to the MUD, or if they use local variables, or if they just read from a variable and don't write to it. There are *lots* of cases where you won't have any problems at all.
And your term "race condition" is a bit too extreme. You aren't going to get crashes, deadlocking, or race conditions...you just might get the wrong value of a global variable if some other thread is also writing to it. For example, if you did this:
| Code: |
| #IF (@globalvar = 0) {#show @globalvar} |
and you have some other thread that changes @globalvar=1, then it's possible that instead of showing the value of "0", it might display "1" (the @globalvar changed between the time of the initial #IF and the #SHOW).
So just don't do that kind of stuff! As I said, the original intent of all of this was to allow some simple situations that people have been demanding...not to make a robust threading system. I'm not going to waste a month of time right now trying to make this perfect just to please one person, when lots of other people could be using this mechanism to perform a lot of simple and useful scripts right now. If you are worried about it not being perfect, then just don't use it.
Let's try to focus on the positive aspects of what you *can* do with the new system, instead of focusing on the stuff that you can't do.
Vorax: Yes, the #WAITFOR command already has the optional timeout argument. The only difference is that the timeout will always abort the script. I don't currently have a good method for resuming the script. Just resuming the script doesn't make much sense since you won't have any results from the pattern (since it never matched). Eventually I'll set up some sort of error mechanism that you can use to determine if there is a timeout. But 99% of the time, you will want to abort the script if you don't receive the expected output from the MUD within the timeout. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
