I have a question regarding POSIX threads on Linux and Solaris. The
program below compiles and links well on both systems, but instead of the
expected "100000, <some number near 100000>" it always prints out
"100000, 0", so the thread is not really ever started.

With Solaris threads I can call thr_yield() and the program works as
expected. There is a call pthread_yield(), but it's not supported on
Solaris (yet), and I don't know if it's official POSIX either.

Interestingly, when I press Ctrl-C during program execution, the other
thread suddenly starts (I guess that's expected behavior).

What am I doing wrong?

HW

P.S.: Please CC your posting to me by mail - I don't get to this
newsgroup too often.

#include <pthread.h>
#include <stdio.h>

unsigned long i = 0;
unsigned long j = 0;

void loop (void *args)
{
  for (;;) j++;

int main (int argc, char **argv)
{
  pthread_t thread;

  pthread_create(&thread, NULL, loop, NULL);
  /* pthread_yield() to "thread" here... */

  while (++i < 100000);

  printf("%li, %li\n", i, j);

  return 0;

-------------------==== Posted via Deja News ====-----------------------
      http://www.**-**.com/ ;   Search, Read, Post to Usenet

h> I have a question regarding POSIX threads on Linux and Solaris.

You have a garbage test program that (a) doesn't do anything useful,
which makes me wonder why you wrote it, and (b) is broken.

h> The program below compiles and links well on both systems, but
h> instead of the expected "100000, <some number near 100000>" it
h> always prints out "100000, 0", so the thread is not really ever
h> started.

That's because main() exits immediately once it is done, and so the
whole program dies.  There is no requirement that all threads run to
completion before the process exits, nor is there any requirement that
threads be time-sliced.  Your main thread should wait for the thread
you create to exit before it exits itself.

h> There is a call pthread_yield(), but it's not supported on Solaris
h> (yet), and I don't know if it's official POSIX either.

pthread_yield() wasn't included in the final POSIX spec.

h> What am I doing wrong?

You are NOT READING ANY DOCUMENTATION.  It helps a lot, believe me.

If I had a penny for every pinhead who posts the same stupid questions
about the same idiot test programs, I could fill a sock with them and
bludgeon the offending posters to death.

        <b

--
Let us pray:
What a Great System.                   b...@eng.sun.com
Please Do Not Crash.                b...@serpentine.com
^G^IP@P6                http://www.serpentine.com/~bos

When your main/initial thread exits all threads of the process
are dismantled.  Your main thread should pthread_join() the threads
it launched before exiting.

Gavin

I recommend reading "A Guide to Multithreaded Programming (Threads
Primer)" by Bil Lewis and Daniel J. Berg (ISBN 0-13-443698-9), ca. 300
pages. It is a great introduction on threads and answers your questions
and also those you haven't asked yet. The question only shows a serious
misunderstanding of threads, so this book is a good place to start.
Don't try programming threads when you don't understand the basic ideas
behind it. That's no flame, I've also just started with threads, but I
began with reading that book which I think was a much better idea than
jumping to writing (wrong) programs immediately (without any
understanding of the matter).

regards, MH

--
Michael Hasenstein, currently @Oracle HQ (Redwood Shores, California)
for Siemens-Nixdorf, Paderborn (Germany)

In article <876232095.25...@dejanews.com>,
        Hans Wegener <hans.wege...@acm.org> writes:

You make assumptions on the synchronity of your threads that you should not
make. Why should the first thread be interrupted by the second one ? On any
reasonable computer counting till 100000 happens within a few milliseconds,
no real reason for a task switch. By the time you enter printf, the other
thread is probably still waiting.

You suggested pthread_yield() in your comments. Interesting enough, it's in
the pthread manual but not in the library. But if you really want to ensure
that the other thread is run before you enter printf, you would have to use
semaphores anyway, since pthread_yield doesn't guarantee you anything ..

Rudi

--

         | | | | |
       \   _____   /      
          /     \                      B O R N
      -- | o   o |  --                   T O
      -- |       |  --                S L E E P
      -- | \___/ |  --                   I N
          \_____/                   T H E   S U N
        /          \    
         | | | | |

In article <yuc4iuv9pip2....@uk.sun.com>,
        Gavin Maltby <Gavin.Mal...@uk.sun.com> writes:

That wouldn't help him either, since he doesn't care whether his threads
cpmplete before the exit call. To make his program work the way he wants
he needs to have the other thread finish before he enters the printf
statement! And that he can only ensure by using semaphores/mutexes.

Rudi

--

         | | | | |
       \   _____   /      
          /     \                      B O R N
      -- | o   o |  --                   T O
      -- |       |  --                S L E E P
      -- | \___/ |  --                   I N
          \_____/                   T H E   S U N
        /          \    
         | | | | |

That's because only one kernel thread is created and thus
no time-slicing occurs.

Do pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM) and
you'll be fine.

Alternatively, you can simulate time-slicing by calling
sched_yield() after every x number of iterations, but that's
painful.

In article <87g1qdin85....@serpentine.com>, Bryan O'Sullivan

Bryan, in order to make even folks like you understand mine is not a
trivial problem I'll explain it to you - slowly and in depth. Perhaps you
might get enlightened.

I am working on an X Windows API port for an object-oriented programming
lanugage that uses a bytecode interpreter implemented in C. The language
supports threads, so I depend on the interpreter running continously.
Some X calls block until the program terminates, so I must have two
threads running - one for the interpreter, one for X, the two
communicating over a queue.

Now, here is the problem: I implemented this with Solaris threads, and
the program didn't work because the X thread didn't start. It didn't even
start after three hundred thousand billion gazillions of hours! (The
argument that the program terminates before the second thread is able to
start doesn't help at all.) I used thr_yield() and suddenly everything
went fine. Since I had to port to Linux, I decided to use POSIX threads,
and the problem was just the same - with the difference that there was no
pthread_yield() available on Solaris, so I had to get an answer to what I
overlooked (as I in fact *did* overlook something).

See above. Your comment does neither solve the problem nor even address
it. I wrote the program to illustrate the technical problem, not to be
prosaic (but I must admit that it led some people to wrong conclusions).
I can easily send you the so-and-so many KB of code I wrote for that X
API if you prefer. The proposed "solution" to let one thread wait for the
other isn't practical, because the interpreter (system) thread may not
wait.

It won't help, believe *me*. Perhaps you got that kind of magic
documentation on your desk that tells you out of the box what other
people in this newsgroup were kind enough to tell me - I don't. I looked
across all available man pages, and there was no single word about why a
thread doesn't start at all - not even in a lifetime.

Let us know when your "What-can-I-do-for-you?"-wizard tells you the
solution to my problem; it can't be too difficult - at least according to
your behavior. Or wait for my next posting and prove you can do it any
better.

Don't! Keep the money, carry it to your bank and after a while take out a
course on good writing style... Or consult
http://www.social-illiterates.org. If I'd depend on any of such
"technical" arguments, I'd be glad to be able to change my job
immediately. (Other insults-in-return available on demand :-)

HW

P.S.: Why actually didn't you have the courage to write such @#%&!?....
stuff to me personally?

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

[cut]

Perhaps your *real* problem is not trivial,  but your illustrating
example is.  It's behaviour will vary depending on such indeterminate
factors as remaining time quantum at the point of thread creation,
number of available LWPs,  available CPUs, priorities of other processes
that might preempt this one etc.  As Bryan and others have mentioned,
you'll need to tool the example up a little more in order to make
it representative (eg,  don't allow main thread to drop off the end
arbitrarily,  consider mutex's and the like for coordinating updates
to variables).  What does pstack have to say about your real application?
Have you tried things under a multithread-aware de{*filter*}?

Cheers

Gavin

Here's a slightly more constructive contribution than my last one.

The main thread waits for a signal from the loop thread before
it continues (usually there may have been some sensible initialisation
performed by the loop thread at this point).  But I chose to
include the condition wait just so we know the loop threads has
been scheduled at least a little.  There is still the possibility
that the loop thread gets prempted after releasing the mutex and
before entering the for loop,  so if the main thread is scheduled
next then it may still print out a zero value for j.

I've still let the main thread randomly drop off the edge as
you had ... not the best approach.

Note that the essential difference to your example is that
I've used the (non Posix threads) thr_setconcurrency() call.
It's not something that is provided in Posix,  but is more than
useful in examples such as yours where some threads never make
blocking calls (or offers to yield CPU).  I don't know what
the suggested equivalent is under other pthreads implementations.

Cheers

Gavin
#include <pthread.h>
#include <thread.h>
#include <stdio.h>

unsigned long i = 0;
unsigned long j = 0;

pthread_mutex_t mp = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cv;

void *
loop (void *args)
{
  pthread_mutex_lock(&mp);
  pthread_cond_signal(&cv);
  printf("loop thread has signalled condiion\n");
  pthread_mutex_unlock(&mp);
  for (;;) j++;

int main (int argc, char **argv)
{
  pthread_t thread;
  pthread_attr_t attr;

  pthread_attr_init(&attr);
  pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM);
  pthread_cond_init(&cv, NULL);

  pthread_mutex_lock(&mp);
  thr_setconcurrency(2);
  pthread_create(&thread, NULL, loop, NULL);

  printf("main thread waiting for signal from loop thread ...\n");
  pthread_cond_wait(&cv, &mp);
  printf("main thread has received signal\n");
  /* have mutex again;  just unlock; loop thread has started but
     may not actually have got to the for loop yet */
  pthread_mutex_unlock(&mp);

  while (++i < 100000);

  printf("%li, %li\n", i, j);

  return 0;

In article <yuc4wwjn2pxd....@uk.sun.com>, Gavin Maltby

The issue is even more confusing than that. I've tried
pthread_attr_setscope() with POSIX_SCHED_SYSTEM on Solaris, and got it
running (Thanks go to Boris Goldberg!). On (my) Linux - where it's
POSIX_SCHED_GLOBAL for some unkown reason - it didn't work. This might be
due to library problems and compilation flags I did not set (see Anders
?stling's post for thread "Pthreads on redhat Linux (Vanderbilt)" in
comp.programming.threads about a month ago) and/or perhaps because it's I
don't have kernel threads (and even how many LWP's and CPU's there are,
as you point out). A colleague told me to avoid POSIX on Solaris
*generally* because they had severe problems with it, but his is not my
opinion.

I didn't know there's something like "pstack" and give it a try on Linux
(hopefully it's available there). I only have "gdb" on that machine and I
guess it's not too advanced in that respect (I only went through "help").

Finally, I promise to post more complex and demanding code next time (just
kidding).

HW

-------------------==== Posted via Deja News ====-----------------------
      http://www.**-**.com/ ;   Search, Read, Post to Usenet

Yes, this is correct.

Just for clarity...

        pthread_yield is an artifact of the obsolete and crufty old
        DCE thread implementation (loose interpretation of the 1990
        draft 4 of the POSIX thread standard). It doesn't exist in
        POSIX threads.

        thr_yield is an artifact of the UI threads interface, which
        is, (effectively though not truly), Solaris proprietary.

        sched_yield is the equivalent POSIX function.

As Robert said, POSIX assigns no particular semantics to the SCHED_OTHER
scheduling policy. It's just a convenient name. In the lexicon that we
developed during the course of developing the realtime and thread POSIX
standards, it is "a portable way to be nonportable". When you use
SCHED_OTHER, which is the default scheduling policy, all bets are off.
POSIX says nothing about the scheduling behavior of the thread.
(Although it does require a conforming implementation to DOCUMENT what
the behavior will be.)

Because there's no definition of the behavior of SCHED_OTHER, it would
be rather hard to provide any guarantees about the operation of the
sched_yield function, wouldn't it?

If you want portable and guaranteed POSIX scheduling, you must use the
SCHED_FIFO or SCHED_RR scheduling policies (exclusively). And, of
course, you need to run on a system that supports them.

POSIX doesn't even say that there's any such thing as a "light weight
process". It refers only obliquely to the hypothetical concept of a
"kernel execution entity", which might be used as one possible
implementation mechanism for Process Contention Scope thread scheduling.

That's not strictly true. All POSIX says is that a thread that blocks
must not indefinitely prevent other threads from making progress. It
says nothing about LWPs, nor places any requirements upon how many there
must be.

SIGINT shouldn't "do" anything to a thread, on a POSIX thread system. IF
it is not handled by a sigaction or a sigwait somewhere in the process,
the default signal action will be to terminate the process (NOT the
thread).

It's not clear from the original posting exactly where the described
results were seen: Linux or Solaris? My guess is that this is Linux,
with the LinuxThreads package. Your threads are really cloned PROCESSES,
and I believe that LinuxThreads still does nothing to properly implement
the POSIX signal model among the threads that compose the "process".
That may mean that, under some circumstances, (and in contradiction to
the POSIX standard), a signal may affect only one thread in the process.
The LinuxThreads FaQ says that SIGSTOP/SIGCONT will affect only the
targeted thread, for example. Although it also says that threads "dying"
of a signal will replicate the signal to the other threads, that might
not apply to SIGINT, or there might be a timing window or an outright
hole where that's not happening in this case.

LinuxThreads is, after all, a freeware thread package that's from all
reports done an excellent job of attacking a fairly ambitious goal. A
few restrictions and nonconformancies are inevitable and apparently
acceptable to those who use it (although it's gotta be a portability
nightmare for those who use signals a lot, you're always best off
avoiding signals in threaded programs anyway -- a little extra
"incentive" isn't a bad thing). If you see this behavior on Solaris,
however, it's a serious BUG that you should report to Sun.

At least, that's true on Solaris, where user threads aren't timesliced.
To get multiple threads to operate concurrently, you need to either
manually create additional LWPs (thr_setconcurrency), or create the
threads using system contention scope (pthread_attr_setscope) so that
each has its own dedicated LWP. Solaris will timeslice the LWPs so that
multiple compute-bound threads/processes can share a single processor.
LinuxThreads directly maps each "POSIX thread" to a "kernel thread"
(cloned process), and should NOT suffer from the same problem. The
kernel will timeslice the "POSIX threads" just as it timeslices all
other processes in the system. On Digital UNIX, the 2-level scheduler
timeslices the user ("process contention scope") threads, so, if a
compute-bound SCHED_OTHER thread runs for its full quantum, another
thread will be given a chance to run.

That's not true. "Hello world" is easy. If the thread just printed
"Hello world" and exited, and main either joined with it, or called
pthread_exit to terminate without trashing the process, you'd see
exactly the output you ought to expect, on any conforming POSIX
implementation. The problem is that the program in question is trying to
execute two compute-bound threads concurrently in SCHED_OTHER policy:
and the behavior of that case is simply "out of scope" for the standard.
The translation of which is that there's no reasonable assumption of a
portable behavior.

/---------------------------[ Dave Butenhof ]--------------------------\
| Digital Equipment Corporation                   buten...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18       http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698       http://www.awl.com/cp/butenhof/posix.html |
\-----------------[ Better Living Through Concurrency ]----------------/

In article <yuc4u3er2lnm....@uk.sun.com>,
Gavin Maltby  <Gavin.Mal...@uk.sun.com> wrote:

% Here's a slightly more constructive contribution than my last one.

Let's just hope Bryan doesn't see it...

[...]

%   pthread_mutex_lock(&mp);
%   pthread_cond_signal(&cv);
%   printf("loop thread has signalled condiion\n");
%   pthread_mutex_unlock(&mp);

[...]

%   printf("main thread waiting for signal from loop thread ...\n");
%   pthread_cond_wait(&cv, &mp);
%   printf("main thread has received signal\n");

This is not going to work. The idea behind the pthread_cond stuff
(which I think is the _right_ way to signal between threads) is that
you test a condition, and then, if it fails, you wait on the condition.
So, you might do something like:

 pthread_mutex_lock(&mp);
 avar = special_value;
 pthread_cond_signal(&cv);
 pthread_mutex_unlock(&mp);

in the `loop' thread, and then

 pthread_mutex_lock(&mp);
 while (avar != special_value)
   pthread_cond_wait(&cv, &mp);
 pthread_mutex_unlock(&mp);

in the main thread. If you do it the way your example does it, the main
thread might never wake up, because if the loop thread signals before the
main thread starts waiting, the signal will be lost and gone forever.

This problem is beginning to interest me. I've only used POSIX threads for
a short time, but I've been using threads under OS/2 for six or seven
years and I've never had trouble getting a thread to run. I may or may
not have had all sorts of other problems, but usually they have been due
to all the threads running and running over each other at that.

What exactly are you doing? If a thread isn't going, where is it stopping?
--

Patrick TJ McPhee
East York  Canada
p...@interlog.com

For the example given, that's not correct.
The main thread holds a lock on the mutex mp and therefore the loop
thread con only signal after the main thread has entered the wait and
given away the lock on the mutex.

But in general, you are correct. Your example shows, how a condition
should be used.

Jochen

In article <876414377.30...@dejanews.com>, Hans Wegener

OOOOPS! Should've read POSIX_SCOPE_SYSTEM...

HW

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet