YakYak

So .. let's assume this scenario ..



And let's assume this very similar scenario ..



The question is "which one is better and why ?".

According to MS docs .. the critical section should be "more efficient" than the mutex, plus it has the bonus
you can use the "spin count" to avoid "using the semaphore and give it a bit more tries" that appearently can be
useful in true multi-processor machines saving CPU time.

The only difference that seems to be ( in such use ) between Mutex and Critical Section is that the Mutex can be
used among different processes ( not threads ) while the Critical Section not but "by nose" looks like the
Critical Section is more efficient way to do that kind of stuff.

Any thoughts ?

Ah the code in those sections is going to be very small and mostly work with an array of pointers to sort out some
things.

It's also going to be a "once in a while event" not a "pretty frequent" one.

I wonder, but let's forget this for now, how in a real multi-core/multi-processor system nowadays the problem of
cache coherency is solved, I suppose that to add volatile qualifier to some vars it's probably not enough, I am not
very expert ( yet ) but I suppose that "multi core" CPUs does not have this problem (?).

Use a Critical Section if your want to synchronize threads in a MS Windows process, it is more lightweight than a Mutex.

Waiting for a Critical Section does not burn any CPU cycles, the thread is simply put asleep. If you are using a volatile you must have some kind of busy-wait loop that will burn cycles.

Ah interesting, this is quite weird .. I thought that Mutex busy == process in sleep .. what's the point to have a thing
like a mutex then if the process is NOT put to sleep ?

Then again I got the impression that the mutex is some kind of object "built using other objects" , I mean the "synch element"
of it I suppose it's "something more basic" than the mutex itself.

Well the volatile thing I was just thinking .. I mean "how the heck it works when you really have multi-cores/cpu that has
to access a shared phisical mem" the famous problem of "the variables with 2 values" .. or 3 .. one is what is really in
the phisical memory, one is what is into cache of processor A and one is what is into cache of processor B..

Cache snooping and things like those, how you can tell a CPU "no look you DO NOT have to cache this fragment
of memory at all", I guess you have to use some "special flag" or form of "malloc()" for that.

Recently I've been using a bit of Waitable timers objects .. I have not found a better way .. but either I haven't found
a very good way at all.

Looks like that "10ms time is all you can ask to Windows", at most 1 ms .. below that I think "or you go by HW" or you
probably are going to kill the CPU by strong polling and querying "high resolution counters" that is not even said they could
be there or work well at all.

Anyway yeah as I said "by nose" was already looking like that "for that use, the critical section is the way to go".

They do the same thing but Enter/LeaveCriticalSection are a lot faster than using a mutex.

Mutex's make a kernel call every time you use them which makes them slow, Enter/LeaveCriticalSection execute almost exclusively in userland (except when blocking) are nice and quick.

If you're doing anything that requires syncing across multiple processes you have to use a mutex.

Yeah I think that's the case, Mutex is more a thing to synchronize different processes rather than simply have access
to a critical section of code.

I tought that even the critical section needed a kernel call but probably whatever it does has to be faster.

Waiting for a Mutex will also put the thread asleep. I was talking about volatiles.

I think volatile will actually work if the variable is small enough to be read or written in one memory access. The CPU handles the cache problems even if there are multiple cores and caches. I don't know how, but there are some smart people at Intel...

Using a volatile can be the way to go, if the wait is very short and you want to react very fast once the resource is free.

A critical section wait will generally spin for a short time, then sleep.

It's far better to busy wait (using a sensible loop, notably with an __mm_pause() built into it) if you are certain that the critical section is typically only held for 'short' periods.

Rolling your own critical section with InterlockedExchange is an order of magnitude fewer cycles than the built-in Windows one, but the Windows one has some nice tricks like not deadlocking if they are nested in the same thread. (That seems to be the main cost of the call to the Windows one, because it needs to reference TLS with an FS: prefix, and that's pretty slow).

1ms seems to me pretty much the limit if you're going to sleep, and you need to use timeBeginPeriod / timeEnd Period to alter the scheduler granularity to make sure you get that (or you tend to get something in the 17ms region - I did, at least).

volatile does not mean what most people think it does in C++. It just suppresses optimisation; it doesn't guarantee memory fencing or global visibility. However, I believe MSVC does now guarantee this, not least because Java's definition does offer these guarantees.

In general, the fastest and simplest way to implement anything like this manually on Windows is to use the built in InterlockedXXX primitives (intrin.h). InterlockedExchange for critical sectioning, and Interlocked(inc/dec) for ref counting, that sort of thing. They guarantee global visibility and fencing. Of course, if you need more than one thing rolled into the commit, you need a critical section of some kind. I usually mark the target vars volatile anyway but that's at least as much to give maintainers a hint that 'this is special shit' as anything else. (It does enable constructs like while (var) for uninvasive probes too though).

It must seems "funny" at times when you see some pepople maybe attaching Z80s with an USB port to a PC and/or some "exotic" microcontroller
with "200 lines of assembler" or such and you think "what the heck are they doing" ?

And then you say "listen, I can generate some Mhz of timing with nanosecond precision and have an interrupt response
time with nanosecond precision as well"

Then you have a PC "hypermegaherz of speed" and you can't even have a 1ms precision, but yeah, given the monstrous
complexity of the OS is quite an incredible challenge to guarantee anything like that, of course even 10ms is quite a thing.

Anyway all this very instructive, one thing I already have it working .. and works .. the other thing Dio I already was thiking
that "I don't think it's even possible to be done that way" and someway you just gave me the confirmation of it

Get yourself a real time OS installed and watch your precision problems melt away...

Precision timing: I suppose you could go mad and set a thread's affinity to a particular core, raise the priority to Realtime and sit on a loop of __rdtsc() calls (RDTSC in asm)... not forgetting to factor frequency changing architectures like Speedstep and the auto-overclocking Nehalem... bearing in mind that the OS may well die if starved on a single cored CPU for too long.

But hey, mad is fun and instructive.

Yeah, that will kill the OS for sure. A single realtime thread can completely change the behaviour of the scheduler, and if there are multiple threads that can take anything approaching a full timeslice in the system, it's a deadlock waiting to happen.