llothar wrote:
> Okay so i have to remove OpenBSD from the list of possible supported
> systems.
> Bad. It's a perfect good extension to the 20 year old pthread standard.
>
>
> But maybe BSD likes to be "State of the Art" of 1985.
> Multithreading was always weak but now with all the dual cores it
> really starts to hurt.
>
The "__threading" keyword has nothing to do with the OS that it is running on;
it has to do with the compiler that you are using. So, if you have the right
compiler for each platform, then you should not have a problem. However, I
would follow Marco's suggestion to stick with the POSIX standard on unix and
don't use it.

Look at it as a challenge. If you know the correct set of calls to make, it
should take less than 5 minutes to work around the lack of compiler support
for what you want. Two sources of into might be helpfull "Programming with
Threads" Chapter 8 (thread specific data) and "man pthread_key_create".

As a separate note, global variables (or global thread local in this case) are
very evil. As an example of retarded code, one can look at "char
*asctime(const struct tm *)". It uses a global buffer to place the result in
and it is not thread safe and multiple calls within the same thread can have
side effects. It is just plain stupid. Now there is "asctime_r".
Theoretically, the original version could be written to use thread specific
data; however, this would impact performance (speed) because accessing thread
specific data is slower than access a regular variable. I also believe that
there are a limited number of thread specific variables that one can have a in
process. So, clearly the "asctime_r" with no global variable usage is wiser.