Post by Ch.Kalyana Krish » Thu, 17 Jan 2002 18:33:41


I am new to pThreads. I am using pThreads Programmin by Bradford
Nichols from O'Reilly.

The code for an example demostrating Conditional veriables is as

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

#define TCOUNT 10
#define WATCH_COUNT 12

int count = 0;

pthread_mutex_t count_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t count_threshold_cv = PTHREAD_COND_INITIALIZER;

int thread_ids[3] = {0, 1, 2};

void watch_count(int *idp){

     while (count <= WATCH_COUNT){
         pthread_cond_wait(&count_threshold_cv, &count_mutex);
         printf("\n watch_count(): Thread %d, Count is %d \n", *idp,

void inc_count(int *idp){

     int i;
     for (i=0;i<TCOUNT; i++){
         printf("\n inc_counter(): Thread %d, old count %d New Count
%d \n", *idp, count-1, count);
         if (count == WATCH_COUNT)


     pthread_t threads[3];

     pthread_create(&threads[0], NULL, (void *(*)(void *))inc_count,
     pthread_create(&threads[1], NULL, (void *(*)(void *))inc_count,
     pthread_create(&threads[2], NULL, (void *(*)(void *))watch_count,

     pthread_join(threads[0], NULL);
     pthread_join(threads[1], NULL);
     pthread_join(threads[2], NULL);


I expected the o/p to contain
watch_count(): Thread 2 count:12
But, it did not. I traced the prog. and found out, by the time the
watch thread checks count - its already beyond 12. So I modified the
code such that the Watch thread - Thread 3 is created first. This
modified the o/p with the watch thread printing :
watch_count(): Thread 2 count: 20.

I am thinking that the watch thread is not able to lock the mutex till
the two threads are done. If it is, what is the use of the conditional
variable and the pthread_cond_signal().

inc_counter(): Thread 0, old count 0 New Count 1

 inc_counter(): Thread 0, old count 1 New Count 2

 inc_counter(): Thread 0, old count 2 New Count 3

 inc_counter(): Thread 0, old count 3 New Count 4

 inc_counter(): Thread 0, old count 4 New Count 5

 inc_counter(): Thread 0, old count 5 New Count 6

 inc_counter(): Thread 0, old count 6 New Count 7

 inc_counter(): Thread 0, old count 7 New Count 8

 inc_counter(): Thread 0, old count 8 New Count 9

 inc_counter(): Thread 0, old count 9 New Count 10

 inc_counter(): Thread 1, old count 10 New Count 11

 inc_counter(): Thread 1, old count 11 New Count 12

 inc_counter(): Thread 1, old count 12 New Count 13

 inc_counter(): Thread 1, old count 13 New Count 14

 inc_counter(): Thread 1, old count 14 New Count 15

 inc_counter(): Thread 1, old count 15 New Count 16

 inc_counter(): Thread 1, old count 16 New Count 17

 inc_counter(): Thread 1, old count 17 New Count 18

 inc_counter(): Thread 1, old count 18 New Count 19

 inc_counter(): Thread 1, old count 19 New Count 20

 watch_count(): Thread 2, Count is 20

I am using Solaris 7.

Any suggestions would be very welcome.

Chadalavada Kalyana Krishna,
National PARAM Super Computing Facility,
Center for Development of Advanced Computing,
Pune University Campus,
Pune - 411007

Fax : +91-20-5694081.


1. a bug with pthread?

[public reply, as I think a few people might be interested in the results]

Without doing this, you will leak memory.  The pthread library MUST keep
information for each thread that exits until it has been reaped, unless it
is detached.  You will find the same "leaky" behavior exists on Solaris
(yes, I tried your program there).

Note also two other problems in your code.  First off
But the pointer that was passed in was on the *stack*.  You can't delete
something from the stack like that (on my glibc6 machine, this causes a core

Secondly (and much worse, IMHO), is the fact that you passed in a stack
structure.  It appears that you have omitted some code, so I will assume
what you do is fill in this stack structure with some data and then pass the
pointer in like you do.  But what if the following chain of events occur?

Fill in data for thread 1.
Call pthread_create for thread 1.
Fill in data for thread 2.
Call pthread_create for thread 2.
--now, thread 1 starts running-- (yes, this is a perfectly valid happening)
--now, thread 2 starts running-- (yes, this is a perfectly valid happening)

You will note that both threads get the data meants for thread 2.  Your
original idea of deleting clt is correct -- clt needs to be in the heap, not
on the stack.

Best of luck!

[code clipped]

2. KDE installation problem

3. pthreads and gdb

4. ftp site for tcl/TK

5. pthreads and the scheduler policies

6. NT 4.0 vs Solaris 2.5

7. fcntl file locking and pthreads

8. Jobs, Jobs, Jobs And More Jobs!!!

9. apache module with pthread library linked crashes Apache 1.3.12 on RedHat Linux 6.2

10. Are pthreads' semaphores supposed to do this or is it a Linux bug?

11. pthreads, GDB, Segmantation fault

12. any luck with pthreads, anyone?

13. pthread and g++ problem