MacOS: fix usage of libdispatch and Availability macros in Thread

[barracuda156]

1. Fix usage of Availability macros: they should not be prefixed with underscores (those are used by internal headers, unprefixed work correctly always).
2. Do not assume libdispatch is always available, that is not the case. Use it where it actually exists.

[icraggs]

As far as I can see there is no alternative implementation if HAS_DISPATCH returns false. What happens then?

[barracuda156]

As far as I can see there is no alternative implementation if HAS_DISPATCH returns false. What happens then?

@icraggs If it is not defined, macro which checks for OSX and HAS_DISPATCH evaluates to false, and a generic posix fallback is used. Conditions under which it gets defined are specified in the header.
Do I miss something here?

I ran the build with and without enabling dispatch, both cases worked. (I have a custom libdispatch which is hidden from environment unless explicitly asked for.)

[icraggs]

The question is does the posix fallback work on MacOS? I remember now - MacOS doesn't support unnamed semaphores, so the fallback won't work. I think we'd need another section for MacOS without the dispatch calls.

[barracuda156]

@icraggs If you could help with switching that to Mach semaphores, that would be great.

I recall mentions about some issues with unnamed semaphores on macOS, though I probably did not encounter actual breakages due to them.

[fpagliughi]

As an alternate overall implementation, consider that semaphores seem to be used as just binary semaphores to be a signal for simple events. That is actually the same usage as how the condition variables are implemented in the library - not to loop and wait on a condition, but to simply wait on the signal, as a simple event flag.

Thus the current implementation of semaphores and condition variables in the library are fairly redundant and can be consolidated.

They could both be replaced with with a single object type that I would suggest would more properly be called an "Event" object. This could be a fairly uniform implementation across platforms, since Windows also has condition variables. But perhaps the Windows implementation could just use the OS Event auto-reset object, since it matches the usage perfectly.

The *nix (non-Windows) implementation can be similar to the existing condition variable code, but I would suggest adding a boolean field as the "signaled" condition and add proper looping checks to avoid problems with spurious wakeups.

I already have a working implementation in a branch in my private fork, here:

https://github.com/fpagliughi/paho.mqtt.c/blob/windows-cond-var/src/Thread.c

My original intent was to explore the use of Windows condition variables to wrap the use of lists into encapsulated, thread-protected, signaled objects, like a ThreadList that internally manages a lock and signal for when items are added and removed.

But this is more exploratory, The code to consolidate semaphores and condition variables into an "Event" object is a nice cleanup, and appears to be working fine. It's really more of a cleanup of existing code than anything novel.

[sikmir]

@barracuda156 is it still actual?