CODEWITHSUNDEEP
cmultithreadingconcurrencypthreads
lbj-ub
lbj-ub

Reputation: 1423

pthreads and concurrency

I have the following code:

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

#define LOOPS 10000

void *run(void *arg)
{
    int id = strtol(arg,NULL,0);
    int i;
    for(i=0; i<LOOPS; i++)
    {
        printf("In %d.\n",id);
    }
}

int main()
{
    pthread_t p1,p2;
    void *res;

    pthread_create(&p1,NULL,run,"1");
    pthread_create(&p2,NULL,run,"2");
    pthread_join(p1,&res);
    pthread_join(p2,&res);
    return 0;
}

When I run this, either the string "In 1" displays 10000 times consecutively then "In 2" displays 10000 times consecutively or vice versa. Shouldn't the strings be alternating and not displaying consecutively as they are here?

Upvotes: 3

Views: 1286

Answers (3)

user703016
user703016

Reputation: 37945

The other two answers are correct, but I'd like to add this:

The two outputs are interleaved. They just aren't interleaved every one or two lines, but more probably thousands of lines. When each thread is given a quantum of time, it has the time of outputting thousands of lines. Since you only print 10k lines on every thread, one has the time to finish its work before the other even starts.

Try replacing your for loop with an infinite loop, and watch what happens.

Upvotes: 2

DigitalRoss
DigitalRoss

Reputation: 146053

Schedulers run processes in time slots. The time slot is big enough to be efficient but small enough to give the illusion of simultaneous execution.

On multicore CPUS, threads that are implemented at the OS kernel level actually will execute in parallel.

On top of this, output is sometimes buffered because it takes about the same amount of processing power to do one big write as it takes to do one small write. Buffering is disabled on most systems when output is going to an interactive terminal device, but now the details of your environment start to really matter.

For the output to be interleaved, it would have to be unbuffered and running on a scheduler that's either multicore or unusually fine-grained and willing to do expensive context switches just because you produced a line of output. If multi-core, the execution paths through the library and kernel would have to be coincidentally balanced on three cores. That's probably never going to happen.

After all, you are creating one at a time and one will always be ready to run before the other.

Upvotes: 2

Bernd Elkemann
Bernd Elkemann

Reputation: 23550

The order in which threads are interleaved by the scheduler is not deterministic (...well it is but only from the scheduler's/kernel's point of view). You should not make assumptions about the order.

In this situation you experience that either one of the threads is allowed to complete their whole work before the scheduler ->preempts it and allows the other thread to run.

Upvotes: 8

Related Questions