Efficiency question: sleep vs waitUntil

[Bad Pilot 0]

I can't: the humour was implicit in my post.

Logically, a sleep command should be more efficient because the system knows exactly how long to leave the thread alone and can set itself a reminder for that time. Meanwhile the waitUntil is like an Obsessive Compulsive, forever going around the house checking that the gas and electricity are off.

[Big Dawg KS 6]

I think I know what will settle this... send a PM to Suma.

[weegee_101 0]

I think I know what will settle this... send a PM to Suma.

That is a splendid idea. I can't wait to hear what he has to say.

[galzohar 31]

Also, is there no variation of waitUntil that has a time limit? I find it hard to do vehicle respawns the way I want without being able to break out of a waitUntil once a certain time limit has elapsed, and any workarounds I can think of are pretty ugly...

[sbsmac 0]

Speaking of scheduling, I still wonder how the engine handles stuff like 2 different scripts doing i=i+1 (where i is global)... In a standard windows program you'd need to use some kind of mutex if you want to be sure your operation is safe, but what about Arma 2 scripting? I suppose that could be tested by running a very large amount of scipts, each performing i=i+1 a large amount of times, and then seeing if the end result is as expected (assuming i doesn't go above its maximum allowed value).

Here's some test code (sorry for the length)...

inCritSection = false ;
runCritSectionTest = true ;

testTask = {
    private ["_i","_z" ];
    while {runCritSectionTest} do {
  if (inCritSection) then {
       player sidechat format ["%1 already in critical section",time] ;
  }  ;
  inCritSection = true ;
  for "_i" from 1 to floor random 1000 do {
       _z = 1 ;
  } ; 
  inCritSection = false ;
  sleep 0.001 ;
    } ;
} ;

sharedVar=0  ;
activeTasks = 50 ;
testAdd={
    for "_i" from 1 to 10000 do {
  sharedVar=sharedVar+1 ;
    } ;
    activeTasks = activeTasks-1 ;
} ;
testSub={
    for "_i" from 1 to 10000 do {
    sharedVar=sharedVar-1 ;
    } ;
    activeTasks = activeTasks-1 ;
} ;

[] spawn {

    player sidechat "running crit section test..." ;
    for "_c" from 1 to 50 do {
  [] spawn {[] call testTask;} ; 
    } ;
    sleep 5 ;
    runCritSectionTest = false ;
    sleep 5 ;
    player sidechat "running shared var  test" ;
    for "_c" from 1 to (activeTasks/2) do {
  [] spawn {[] call testAdd;} ; 
  [] spawn {[] call testSub;} ; 
    } ;
    waitUntil {activeTasks ==0;} ;
    _s = "PASS" ;
    if (sharedVar != 0) then {_s = "FAIL" ;} ;
    player sidechat format ["Finished var test - result %1 (%2)",_s,sharedVar] ;

} ;

Conclusion from my tests is that the level of atomicity is probably individual statements. Ie, you often see critical section violations but shared variables have (so far) always returned the correct result.

Also, is there no variation of waitUntil that has a time limit?

What's wrong with

_t = time ;
waituntil {someCondition or (time > _t +delay);} ; 

Logically, a sleep command should be more efficient because the system knows exactly how long to leave the thread alone and can set itself a reminder for that time

And how do you think the 'system' does that ? :) One possible implementation is to maintain an ordered list of waiting threads/tasks but that means overhead every time you add one to the list since you have to do it in the right place. The other common one is to just set a wake-up time in the thread structure but then all that happens is that the scheduler has to check this for every thread every time it runs - in other words, no different in practice from checking the time within the script.

[wiper 0]

And why would you think that ArmA2 would implement this significantly differently from ArmA1?

because of a simple fact maybe ? :) :

Due to an error in the code I hade once a loop (without delay) running endless and in *multiple* scripts at the same time in Arma1.

Arma hung up almost hopelessly and I was lucky just in some of these occurencies to ESC back out to the menu/editor.

Happend relatively often to me in Arma1

In Amra2 yet not one single time.

Even had a similar glitch some days ago (multiple endless loops at the same time) and all that happend was an extreme FPS drop , down to 5-10 from 60.

go figure ;)

Edited August 13, 2009 by Wiper

[sbsmac 0]

That's not a difference in the waitUntil implementation, it's a change in the way the script scheduler is able to deschedule scripts. :)

[.kju 3240]

Did you guys read this yet?

in order to maintain smooth frame rate in real-time content, time limit for all scripts in each frame is enforced by the engine in ArmA 2. Generally speaking, in case of more demanding scripts, be prepared that their result may come way later and also there probably can suffer from significant latency. It is under evaluation if and how possibly allow user scripts to change how much time they may take from the CPU in every frame.

http://community.bistudio.com/wiki/ArmA:_Editing#Forward_Compatibility

[Bad Pilot 0]

Yeah, that's partly why I'm talking about a scheduler.

And how do you think the 'system' does that ? :) One possible implementation is to maintain an ordered list of waiting threads/tasks but that means overhead every time you add one to the list since you have to do it in the right place. The other common one is to just set a wake-up time in the thread structure but then all that happens is that the scheduler has to check this for every thread every time it runs - in other words, no different in practice from checking the time within the script.

The semi-hypothetical scheduler is already checking what's due to happen. Adding something to the list has little effect on performance as the list-item is not even looked at until the time it is needed.

Computing a waitUntil (or the other kind of trigger) is relative hell for the processor because the required condition could sneak up on it from any direction.

Here I am become a half-baked philosopher! Suma, put us out of our misery!