🚀 go-pugleaf

pete@puffin.uucp (Pete Carah) writes:

>>This is necessary if each thread gets its own copy of errno...
>The SGI solution to this (I use their thread implementation in some
>semi-parallel image processing stuff) is to have a function that returns
>errno (from a private data area).  This area may be a non-shared page
>or it may be shared with a unique pointer; I don't remember.  In any
>case, this solution requires a library which is different from
>the normal library whenever you use threads; this is needed anyhow since 
>you have to serialize the use of the _iob structures and the malloc arena.
>They then provide a function to access (and another to set) errno.
>This communications block may not be shared; I may have read things wrong;
>it acts as if it isn't.

The SGI solution is to have a function `int *_os_error(void)'.
Errno is defined as (*(_os_error())). (or some such). Any way,
there's a function returning a pointer to errno. A different
pointer for each thread, I assume. Whether SGI uses different
libraries for threads, I don't know. The include file sure don't
make me think so. The define for getc reads somethink like this:

#define getc(f) (_have_threads ? _sem_getc(f) : < your regular getc code >)

This sure look like a runtime decision to me.

>>How (or does) gcc plan on getting around the problem?
>gcc isn't really part of the problem; it can be solved in the library
>and/or the page manager (with the cooperation of the linker).
>Remember that errno is a library construct, and any program using
>threads MUST be aware that it is using threads.  There are MANY
>problems that come from sharing an address space that aren't addressed
>here (you may have to serialize access to any address depending on the
>program semantics; unix/C requires you to be aware of this.  Yes,
>there are parallel systems with this built-in; many of them program
>in C and use function calls or split pages with a special library
>manager to implement arbitration.

Specific problems, like errno, can easily be dealt with in libraries.
A more general solution (user defined thread local storage) is
much harder to implemen without help of the compiler.

I don't agree that any program that uses threads should really be aware
of the fact. I can imagine some library functions that swpans a thread and
immediately while a thread remains runnign to perform some task.
I also believe that thread awareness shouldn't lead to constructs like:

	mutex_enter(errno_mutex);
	system_call;
	save_errno = errno;
	mutex_leave(errno_mutex);

All the lowlevel stuff that can easly handled out of sight should
be handled in such a way.

>C is NOT a parallel language; making it that will require much more
>than a pragma.  The implementors of C were using the KISS principle,
>forcing all OS-(and other context)-dependent constructs into functions
>from the library.  I realize that ANSI has muddied this, but it still
>remains that C itself contains nothing to either aid or hinder thread
>programming; all of that rests in the library.

The standard C and POSIX libraries contain lots of examples of
static storage used in return values of functions. All of these
are extremely hard to make thread-safe without a notion of thread
local storage. I find it very hard to think of an implementation that
doesn't require any support from the compiler/linker.

>BTW - it's real easy to shoot yourself in the foot using threads; if
>you think C is bad that way by itself, try threads...  Even Ada, where
>the tasking/rendezvous is built into the language (now admitted to be
>a mistake by some of the early implementors), lets you shoot yourself
>in the foot very easily using shared data.

Sure. That's why you need as much support as you can get. You cannot
have threads without MT safe libraries. Language support
for thread local storage seems to be needed.
(I know, we've strayed a long way from gcc. I hope somene will
find the time to implement #pragma unshared() for Solaris
or thinks of a way that is superior to this and implements that)

Casper