Why pthread_create sometimes takes a long time?

I’ve a problem:
Starting a thread sometimes takes a “very long” time.
I measuered the time directly before calling pthread_create and directly after it. The time it takes to start the thread is between 0 ms and up to > 150 ms:

1: 0.000000 ms
2: 0.000000 ms
3: 0.000000 ms
4: 0.999847 ms
5: 44.993115 ms <—
6: 0.000000 ms
7: 0.000000 ms
8: 0.000000 ms
9: 3.999388 ms
10: 0.000000 ms
11: 172.973531 ms <—
12: 0.000000 ms
13: 0.000000 ms
14: 0.000000 ms
15: 0.999847 ms
16: 0.000000 ms
17: 0.000000 ms
18: 0.000000 ms
19: 47.992656 ms <—
20: 0.999847 ms
21: 0.000000 ms
22: 45.992962 ms <—
23: 0.000000 ms
24: 75.988372 ms <—
25: 0.000000 ms
26: 0.000000 ms
27: 3.999388 ms
28: 0.999847 ms
29: 0.000000 ms
30: 75.988372 ms <—
31: 45.992962 ms <—
32: 0.000000 ms
33: 0.000000 ms
34: 0.000000 ms
35: 1.999694 ms
36: 40.993727 ms <—
37: 0.000000 ms
38: 40.993727 ms <—
39: 0.999847 ms
40: 0.000000 ms
41: 0.999847 ms
42: 0.999847 ms
43: 0.000000 ms
44: 5.999082 ms
45: 110.983017 ms <—
46: 73.988678 ms
47: 0.000000 ms
48: 0.999847 ms
49: 4.999235 ms

The treads start in a loop. So there may be several of those threads at the same time.
These are the attributes I use for the thread:

pthread_attr_init (&threadAttr);
pthread_attr_setdetachstate( &threadAttr, PTHREAD_CREATE_DETACHED );
pthread_attr_setschedpolicy ( &threadAttr, SCHED_FIFO) ;
pthread_attr_setinheritsched( &threadAttr, PTHREAD_EXPLICIT_SCHED) ;
nPrio = getprio(getpid()) - 2 ;
tSchedParam.sched_priority = nPrio;
pthread_attr_setschedparam ( &threadAttr, &tSchedParam) ;

So my question is:
Why does the creating of the threads sometimes takes so long and how can I solve the problem?

Thanx a lot in advance.

How you know in you test program, that the thread is create?

each thread stores a picture as a bmp-file. So if the files do exist, the thread must have been created

<< So if the files do exist, the thread must have been created>>
Time to exist the file is related on devb-eide driver options and this time may be up to 2 sec.(by default)…

Thanx for your answer. But I don’t understand “Time to exist the file” :blush:
Do you mean the time to create the file?
But the creation is IN the thread. So just starting the thread shouldn’t take so long.

How you measure the time to create a thread?

I measure it like that:


clock_gettime( CLOCK_REALTIME, &tStart [n]);
pthread_create (&thread, &threadAttr, BMPCreator, (void *) &tbmpattr);
clock_gettime( CLOCK_REALTIME, &tStop [n]);


Later I print it, like that:
printf ( “%i: %f ms \n”,
(tStop[n].tv_sec - tStart[n].tv_sec ) * 1000 +
(double)( tStop[n].tv_nsec - tStart[n].tv_nsec )/1000000L );

try to use sched_yield after creating a thread

Thanx for your help. but - sadly - sched_yield has no effect:
several threads still take very long to start.

It could take 2 seconds for the files to be physical move to the device, but for any program that reads it, it present as soon as it’s created. The read data comes from the cache.

You are also saying the threads are started in a loop, will maybe the first couple of threads are stealing away from CPU. Starting them at a level of priority 2 below that of the mean thread, is not a guaranty because the thread will float to the priority of the event they receive.

Clock_gettime precision is based on the ticksize.

You are not ONLY measuring the time to create the thread. For example if the thread that is started gets the CPU right away it will use the CPU and run for a while before the thread that did the creation gets the CPU back.

Try sched_yield() as the FIRST operation of the newly created thread. Note that if the threads are higher priority (or receive an event of higher priority) then the thread that created them sched_yield() will not make a difference).

If you want to REALLY know what happen use the instructement kernel and the tools provided in Momentics SE to see everything the kernel did.

use ClockCycles() instead clock_gettime()

Use the System Profiler to see the actual time it takes to create the threads! Your threads don’t need to do anything for this…