 |
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
 Posted: Sat Dec 22, 2007 6:37 pm
#SECTIONing Problem
|
I decided it would be a really good idea to have some of the scripts that revolve around user inputs rather then triggers to jump into a background thread when they might take a while. Here is most of the code for handling it.
| Code: |
$OldThread=%threadname()
#IF (%threadname("BuildMapReport")) {
#SHOW "Warning in BuildMapReport: Another build is in progress, locking this one down."
#WAIT
#SECTION LockBuildMapReport {
#WAITTHREAD BuildMapReport
#CALL %threadname(,"BuildMapReport")
}
} {
#CALL %threadname(,"BuildMapReport")
#IF (%numitems($RList)>30) {
#SHOW "Warning in BuildMapReport: Lengthy build detected, jumping to background thread"
#WAIT
}
} |
Now where I see a problem happening is a small thread timing window between these lines, particularly at the "#WAIT".
| Code: |
#IF (%threadname("BuildMapReport")) {
#SHOW "Warning in BuildMapReport: Another build is in progress, locking this one down."
#WAIT
#SECTION LockBuildMapReport { |
I can't eliminate that #WAIT because it needs to jump to the background before it gets suspended awaiting its turn with #SECTION. What I really need to be able to do is this.
| Code: |
StartSection ClaimBuildMapReport
#IF (%threadname("BuildMapReport")) {
#SHOW "Warning in BuildMapReport: Another build is in progress, locking this one down."
#WAIT
EndSection ClaimBuildMapReport
#SECTION LockBuildMapReport {
#WAITTHREAD BuildMapReport
#CALL %threadname(,"BuildMapReport")
}
} {
#CALL %threadname(,"BuildMapReport")
EndSection ClaimBuildMapReport
|
Of course the the way the #SECTION command works I can't do that. I also can't see anyway to make it so that there is no possiblity of a race condition without that. I have to be able to do it with a #SECTION because I don't want the function to go into the background unless it must. That configuration blocks subsequent calls from going through before one has adequately established its position in line. Notice how the Claim section is fast, and even if multiple threads race between the EndClaim and LockBuild sections it won't cause any harm because only 1 will make it through and all those that raced there will be forced to the background. Does anyone see anything I am missing here? Another way to actually do it? |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Sun Dec 23, 2007 1:13 am
|
I think I figured out how to write it. It isn't very processor friendly since it actually uses this loop at the end to hold the EnterCriticalSection function.
| Code: |
#WHILE ($MyTicket) {
#SECTION CriticalSectionHandler {
#IF (%word(%db(@SpecialSectioningData,$SectionName),2)=$MyTicket) {$MyTicket=0}
}
} |
I still have to test it extensively, but it looks like this will be doable.
Preliminary testing seems to indicate that I can also cover failure to preform a LeaveCriticalSection. However, the coverage comes in the form of a seperate thread that is using #WAITTHREAD to detect the end of your script. I think Zugg mentioned he adjusted the maximum time slice a thread can have to 250ms before it would pass to another. Considering that and the #WHILE above you can see that it would be easy to bog a system down with only a few attempts to enter the same section.
This will be part of my Toolbox, but I would like to caution anyone that considers using it to make sure you know what you are doing before using it. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
|
|
|
|
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
|
|
