Zugg Software :: View topic - [2.36] Threading troubles

Enchanter Joined: 09 Sep 2007 Posts: 605

I want to ask for some help with my threading problems while Zugg is unable to respond on this having his hands full with the mapper. I know that it's all too complicated

I have a thread with internal queue (local string list) and an alias that adds elements to intermediate public queue. Once per specified amount of time the thread checks if there are any new elements in the public queue and if they are, moves them to internal queue.

ComLine -> Enqueue alias -> #SECTION{Public queue} <- THREAD ->(local queue)

Everything is cool while I'm calling enqueuing alias not so many times per second (about 3-4 commands per second), so basically my system works. But under some specific stress test conditions sometimes CMUD makes weird things. It can, for example, terminate running thread or, as I saw in my primary package, stop recognize existing aliases as if they were out of scope (ultimately this leads to a crash on CMUD close with messed up pointers). So I can't say that my script is working 100%, but I can't find any flaws in it as well. May be I just missed something?

At the end of this post you can see my threading script from which I've carved up all the unneccessary "meat" and to which I've add several tracing #PRINT statements. I've already check that with this shortened test script I see all the same symptoms I saw in its full version, so I guess that problem was isolated. Can you see any obvious errors in the threading algorithm, in the #SECTION code blocks? If you can't see any serious flaws, then I suspect that there is a problem with #SECTION command.

Usage:
run - start the "WorkingThread" thread
stop - stop the "WorkingThread" thread
enqueue X - this alias adds an integer with value X to the intermediate public queue (X must be >=0).

Stress test: make sure that you do not have "clear the command line" option enabled. Enter at the command line something like enqueue 5. Now, press your Enter key rapidly, 10 or more times per second - get your main thread busy! Do not hold the Enter key in pressed state, don't do #LOOP 15 {enqueue 5} - these cases seems work properly. MAY BE this all is system dependent things and on your more powerful computers you will not see anything - I really don't know. On my machine sooner or later I'll see that "WorkingThread" thread has stopped.

Analyzing logs
This I saw in the script debugger:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I see a few problem lines in your debug log, and it looks to be a bug in CMud. This is definitely a very tight timing bug, but your procedure and script should make it replicatable. For ease of replication I would suggest adjusting the #WAIT 500 down to #WAIT 50. This looks to be problem spot

Enchanter Joined: 09 Sep 2007 Posts: 605

It appears that every time a thread waits when another thread will leave a #SECTION code block, one of these threads gets terminated at the end.

10:46:17.453p | c untitled | [52] untitled Comline : start :
10:46:17.453p | a untitled |Moving value from public queue to internal: 0
10:46:17.453p | n untitled | Exec Alias "Enqueue"
10:46:17.453p | a untitled |Moving value from public queue to internal: 0
10:46:17.453p | d untitled | [52] untitled Comline : wait for section: : SectQueueAccess
10:46:17.453p | a untitled |Moving value from public queue to internal: 0
10:46:17.453p | a untitled |Moving value from public queue to internal: 0
10:46:17.468p | k untitled | [WorkingThread] Var "PendingInts" changed from "0|0|0|0|0|0" to ""
10:46:17.468p | k untitled | [52] Var "PendingInts" changed from "" to "0"
10:46:17.468p | a untitled |INTERNAL queue: 0|0|0|0|0|0|0|0|0
10:46:17.468p | d untitled | [52] untitled Comline : terminated

And while CMUD itself can run another thread for handling the command line instead of terminated one, the working thread can't be restarted automatically, making this error visible. In other words, when such things happens for command line thread, CMUD hides this error by launching another thread, but it can't do that for user threads. In my debug log posted above the main thread ID had get to 53 for only about 2 minutes!

So again, I think that there is a problem with the #SECTION command. I've asked Zugg about the #SECTION and he told me that it is just a wrapper for WinAPI calls. I'll hope that it is a bug in the wrapper, otherwise I'm not sure is this problem fixable at all.

Vijilante:
I have absolutely forgotten that I can reduce the number of milliseconds to wait. Thanks for the tip!

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Everything looks right in you most recent post.

I don't think the problem is with #SECTION directly. I don't really have time to explain it right now, but below is a test that isolates just the #SECTION command.