Both methods can use MT for a common shared variable pool. (R/W lockable)
I'm afraid this statement isn't true, at least your script listing reads to the contrary. You see, your
sb_msSleep(10) in the main thread enables the worker thread to write a new value into main::a
unhindered while the main thread idles for almost 10 milliseconds and thus gives no chance to its subsequent read access to main::a in SB_GetVar() to collide with the worker thread's concurrent write access to the same. A write access to a single memory variable will take on the order of a few nanoseconds only, which is incongruously faster than the main thread's 10 millisecond idle period, thus precluding efficiently the said collision
without any special alleged read/write locks on behalf of SB memory manager.
From what I used to see in the SB memory manager code, there were no access collision prevention options there.
(they would inevitably slow things down for single-threaded applications where memory mutexing isn't necessary)So, it isn't the SB memory manager that resolves the R/W access conflict automatically, but rather your own code, even if you don't fully realize it.
Now generally, what happens if you specify
sb_msSleep(0)?
(that is, out of this particular code context)Under Windows, Sleep(0) has a special meaning of "yield the rest of own time slice to the other concurrent threads in the process", so that they could run faster/longer while the given thread idles on account of its task having been already fulfilled. The duration of thread time slices is normally scheduled by the system Task Manager automatically based on the number and priority of all threads in the process, but Sleep(0) can override this default behavior.