TQSLEEP maybe need check tq_lock

[jzy-chitong56]

In both crashes, an AI process ran to TQSLEEP (but no thread was adding TQAddJobEx). You previously mentioned that tq-lock was to prevent other threads from modifying tq_1ength

but for safety reasons, I still recommend TQSLEEP to check tq-lock

[SMUnlimited]

Easy to test: https://github.com/SMUnlimited/AMAI/commit/f361cb17d3e11dec4ddbbb1544cb82fd63d3dd35

[jzy-chitong56]

when TQSleep check tq-lock need to record the time that has passed in the loop and add it up, which is the most accurate way

like

function TQSleep takes real time returns nothing
  local integer i = 1
  local real t = TimerGetElapsed(tq_timer)
  call GetTQLock()
  set t = TimerGetElapsed(tq_timer) - t + time
  loop
    exitwhen i > tq_length
    set tq_time[i] = tq_time[i] + t
    set i = i + 1
  endloop
  call ReleaseTQLock()
  call Sleep(time)
endfunction

[SMUnlimited]

Not necessary, because this shouldn't even be possible to lock for a long time as it will always be called from within a job, and if it does extra wait we don't want to add that wait time as it wasn't expected by the job when scheduled so we other jobs that timer has met to fire and not delay further.

[jzy-chitong56]

Invalid, the crash still occurred

Is it possible that the waiting time here is too short？ TQLoop -- call Sleep(RMax(0.05, GetRandomReal(0, 0.3)*sleep_multiplier)) OneBuildLoopAM -- call Sleep(0.05) call Sleep(0.02)

[SMUnlimited]

Shouldn't do as then there would be lots of problems in other mods and maps. Also the sleep can end up being longer for these small amounts based on the whims of the war3 engine.

Problems at the thread level usually take out the thread itself not the whole game.

Only way I know for game to crash is if number of operations running within a single GPU frame across all threads is too large. With more players you have more threads running at the same time.

[SMUnlimited]

Closing this issue as it didn't help.