Why isn't this thread determinist?

[MaSSaSLaYeR]

Hello,

I got critisized today that this program isn't determinist?

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
struct Param
{
char c;
};
void *threadTest(void *p)
{

int i;
struct Param *param = (struct Param*)p;
for(i = 0; i < 1000; ++i)
    printf("[%c]\n", param->c);
return NULL;
}
int main(int argc, char *argv[])
{
int i;
pthread_t t1, t2, t3;
struct Param p1, p2, p3;
p1.c = 'b';
p2.c = 'c';
p3.c = 'd';

if(pthread_create(&t1, NULL, threadTest, &p1) || pthread_create(&t2, NULL, threadTest, &p2) || pthread_create(&t3, NULL, threadTest, &p3))
{
printf("Fout bij aanmaken thread!\n");
//abort();
}

if(pthread_join(t1, NULL) || pthread_join(t2, NULL) || pthread_join(t3, NULL) )
{
printf("Fout bij aanmaken thread!\n");
//abort();
}
for(i = 0; i < 250; ++i)
printf("a\n");
//)exit(1);
}

+ How do I make *threadTest run only once for 1000 sec and then stop that thread?

Kind regards!

[grumpy]

It is not deterministic because the operating system can preempt each thread, and run parts of them in different order. The output is therefore unable to be determined.

Instead of using threads, just call threadTest() directly. That way, each function call will complete before the other is called.

Advanced note: Strictly speaking, that is still insufficient to achieve determinism. Unless you compile and run your code on a suitably configured realtime operating system (RTOS) or directly on hardware, then the operating system may preempt your program in order to run other threads or processes, and the actual time it takes to execute each function call in your program cannot be determined. Strictly speaking, determinism includes ability to pre-determine the sequence of events (which your critic is obviously concerned with) AND also timing (which your critic is presumably neglecting).

[MaSSaSLaYeR]

It is not deterministic because the operating system can preempt each thread, and run parts of them in different order. The output is therefore unable to be determined.

Instead of using threads, just call threadTest() directly. That way, each function call will complete before the other is called.

Advanced note: Strictly speaking, that is still insufficient to achieve determinism. Unless you compile and run your code on a suitably configured realtime operating system (RTOS) or directly on hardware, then the operating system may preempt your program in order to run other threads or processes, and the actual time it takes to execute each function call in your program cannot be determined. Strictly speaking, determinism includes ability to pre-determine the sequence of events (which your critic is obviously concerned with) AND also timing (which your critic is presumably neglecting).

But it has to be threaded, can't I do a sleep or a wait to make it more determinist? The problem kinda is that the threads can run at the same but they have to stop at the same time.

[QuantumPete]

But it has to be threaded, can't I do a sleep or a wait to make it more determinist?

No, the operating system with all its wisdom will decide on how to schedule your threads. It may run them one after the other or round-robin between each statement. There is no way to know and it could change every time you run your program.

[grumpy]

But it has to be threaded, can't I do a sleep or a wait to make it more determinist? The problem kinda is that the threads can run at the same but they have to stop at the same time.

You haven't provided any justification for your claim that it has to be threaded. Threads are intended for circumstances where you don't care what order things are done. If you care about the order things are done (which is what, mistakenly, you are describing as "determinism") then don't use threads.

Using sleep() or wait() does not change that.

[MK27]

But it has to be threaded, can't I do a sleep or a wait to make it more determinist? The problem kinda is that the threads can run at the same but they have to stop at the same time.

Doing it with a sleep() totally negates the point of threading. Also, it is still not guaranteed to work -- it usually will if the tasks are short and you use a long sleep (making the whole thing much slower than a single threaded process), but it is still possible, particularly if the OS is busy, for a thread to do something, sleep, and get scheduled again before another thread of the same process.

The way to synchronize threads is to use mutexes, semaphores, and/or condition variables (which require a mutex). Do not try and make up your own scheme without the use of mutex's or semaphors. You may think it must work, and it may seem to, but it is unsafe.

[MaSSaSLaYeR]

Doing it with a sleep() totally negates the point of threading. Also, it is still not guaranteed to work -- it usually will if the tasks are short and you use a long sleep (making the whole thing much slower than a single threaded process), but it is still possible, particularly if the OS is busy, for a thread to do something, sleep, and get scheduled again before another thread of the same process.

The way to synchronize threads is to use mutexes, semaphores, and/or condition variables (which require a mutex). Do not try and make up your own scheme without the use of mutex's or semaphors. You may think it must work, and it may seem to, but it is unsafe.

Thanks for your reaction I got problem with the Dining Philosophers & mutex will post in another thread