🚀 go-pugleaf

In article <1sbsjv$2fv@mail.fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes:
>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
>
>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

Not in the library I use; they use a function to set errno and another
to read it; no pointers given.  They do tell you (if you ask on comp.sys.sgi)
how to figure out where it is in the thread-unique page of memory.

>pointer for each thread, I assume. Whether SGI uses different
>libraries for threads, I don't know. The include file sure don't

Yes; -lmpc is required if you use threads (well, really if you use
stdio or malloc under threads - I don't know what else they
serialize or protect).

>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.

It is; that's the only way you can have the same include file for
both cases, where getc is implemented as a macro.  Note that it isn't
a macro under the thread library - they set that _have_threads variable.

>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.
SGI does; just use -lmpc instead of -lc (they require it anyhow).
Note that the requirement is loose; they actually do define the sproc
to work in -lc, so you can really shoot yourself in the foot if desired.

>>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.
Those *can* all be changed in the libraries if desired; with enough
memory a GC scheme could be implemented to get the required malloc
memory back.  I think those static returns aren't a good idea even
in the old days.  Support from the linker is different from that of
the compiler; you need to change the semantics of the language itself
to do some of the things you are talking about.

>>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)
Well, malloc gives you unshared memory; the SGI implementation doesn't
have unshared statics or globals and I haven't felt a problem from it.
(except for one global that points to a struct in high memory that
is distinguished from the others by the page-handler)

I can see that it could be nice but one can (usually) get along anyhow.
BTW - try to figure out how pragma unshared would work; without the
compiler knowing ahead of time how many threads could be going at once -
I decide this over a pretty wide range at run time depending on whether
I'm on a multiprocessor machine or not and whether the primary disk
access is local or NFS.  It would actually seem to need a malloc'd area
that the thread-fork (sproc in SGI) would allocate and fix up at run
time for each thread, and probably hidden stack variables for each
thread to point to them (like argc/argv/envp in the top level; they
are implemented more-or-less this way by the OS).

Remember, most people consider C to be a slightly complicated assembler;
(tho ansi C is really not; things have gone very far from the original
ideas if the original implementors).  If you want a true parallel
language, there are some out there, none very popular.

Threads as currently implemented work fine (in C) for coarse-grained
parallelism; ask e.g. convex for info how they do fine-grained stuff.
Also see many papers in the high-energy theoretical physics literature
for kluges to use C or Fortran on thousand-node-ish MIMD systems.
(most of those don't share memory but instead use message-passing for
communication, though).  I know of one that mixes these models; it
can run more than one "site" on a given hardware node.  The intercommunication
is still handled by the same (library) primitives, so the programmer
isn't aware of which ones share memory (except by timing, as usual).
I'm not sure if his stdio is still macros, or if he uses errno :-)
(those are *NOT* C; they are OS dependent.  Try in VMS (or MVS) to use the
concept of a file as a stream of bytes transparently).  Many people
think that's part of C; it isn't.

-- Pete