SEO

I write a portable multi threading platform program.
Solaris and Linux (with glibc 2.3) both know the

__threading int myvar;

declaration to declare a thread local variable. Is this also
implemented in the BSD Versions (Open,Free,Net) ? I don't want to use
the uncomfortable "pthread_set/get_specific"

"llothar" <llothar@web.de> writes:

> I write a portable multi threading platform program.

Keeping this in mind...

> Solaris and Linux (with glibc 2.3) both know the
>
> __threading int myvar;

you mention non-portable extensions

> declaration to declare a thread local variable. Is this also
> implemented in the BSD Versions (Open,Free,Net) ? I don't want to use
> the uncomfortable "pthread_set/get_specific"

then bitch about using the portable POSIX defined functions. Either
use the standard functions or limit your code to those OS that implement
the non-portable extensions. Can't speak for FreeBSD or NetBSD, but
OpenBSD does not (and can not [I think] given the current implementation)
support something like "__threading int myvar;"

// marc

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.

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.

In article <1132433524.292718.274390@g47g2000cwa.googlegroups .com>,
llothar <llothar@web.de> 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.
>

Whine, whine, whine.

Poor child.

First, you tell us that you're writing a portable library.
Then we tell you in no uncertain ways that what you're doing is not
portable.

So you come back and redefine `portable' to be whatever arranges you,
and gripe at OpenBSD for not implementing every new-fangled extension
to every other OS.

GROW UP!

I'm pretty sure that, with your attitude, I don't want to use your library.

Go take a walk, learn how to write portable code, and come back.

Jack <jhammer.noemail@yahoo.com> wrote:
> 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.

As far as I understand TLS (thread local storage), what's required is
compiler, linker and library cooperation. Which is why the support isn't
wide spread; there's lots of platform retooling required to get TLS
implemented. Linux only got it recently, in fact.

> However, I would follow Marco's suggestion to stick with the POSIX
> standard on unix and don't use it.

TLS is extremely useful. Had it been required when POSIX Threads debuted we
could have sidestepped a decade of kludgy _r library extensions and
countless coredumps and exploits. Unfortuantely, TLS isn't widely supported.
AFAIK, only [recently released versions of] Linux and Solaris provide
support. FreeBSD might be close if they don't have it already.

In any event, I have to concur that to be portable by any streth of the term
you need to stick to getspecific()/setspecific().

OpenBSD would probably be last since the team doesn't care to add fancy
features to the linker, and pthreads support is still on the move.