Entangled in Threads

i have tried reading about threads but nothing is yet clear to me. i also tried copying a program from the book but still i am not at all clear how does it work and what is actually is. I just started using Linux programming some days back and i really need help with this concept to continue further. would someone please take some time and pain to explain it. please

thx a lot.

Hello
Especially in this program : the output is arbid repetition of x and o and is a complete bouncer to me.

#include <pthread.h>
#include <stdio.h>
/* Prints x’s to stderr. The parameter is unused. Does not return. */
void* print_xs (void* unused)
{
while (1)
fputc (‘x’, stderr);
return NULL;
}
/* The main program. */
int main ()
{
pthread_t thread_id;
/* Create a new thread. The new thread will run the print_xs
function. */
pthread_create (&thread_id, NULL, &print_xs, NULL);
/* Print o’s continuously to stderr. */
while (1)
fputc (‘o’, stderr);
return 0;
}

https://computing.llnl.gov/tutorials/pthreads/

http://www.yolinux.com/TUTORIALS/Lin...ixThreads.html

http://randu.org/tutorials/threads/

http://en.wikipedia.org/wiki/POSIX_Threads

-----------

These are just a few of the hits I got when Googling "tutorial pthread" and "wiki pthread".

I would recommend that you learn to use Google before attempting to tackle pthread development.

Threads are used for parallel executions . ( a few functions executing @ the same time )
when you create a process , it has 1 thread but you can add more to it by creating new threads , assigning them stuff to do .
when it comes to threads data access is pretty important , ( 2 threads accessing a data @ the same time will cause a lotto problems )
thats why some languages support syn .... i dont know the exact word , to avoid that .

In the case of your program , the two functions main() and print_xs() are executing simultaneously printing x o x o x o

hope that will help you .

Originally Posted by chymeira Threads are used for parallel executions . ( a few functions executing @ the same time ) when you create a process , it has 1 thread but you can add more to it by creating new threads , assigning them stuff to do . when it comes to threads data access is pretty important , ( 2 threads accessing a data @ the same time will cause a lotto problems ) thats why some languages support syn .... i dont know the exact word , to avoid that . In the case of your program , the two functions main() and print_xs() are executing simultaneously printing x o x o x o hope that will help you .

Actually, on a system with a single CPU, the threads do not execute simultaneously. They are provided a time-slice just like any other process. The main feature of threads is that they are light-weigh processes that share the same program space as their parent thread (or main thread). Thus global data (yuck!) is accessible by each of the threads.

You were correct in mentioning that access to complex data does require that the threads employ a semaphore, mutex, or other means to prevent "concurrent" access to that data. The word you were looking for earlier is "synchronized", which is used in Java and maybe other high-level languages. In C and C++, no such concept exists, thus one must create their own lock to prevent two threads from accessing data at the same "time". pthread_mutex() is one such tool in this case.

The output of that test program will be a randomly assorted stream of x and o since the threads (which execute like independent processes) will get to use the CPU according to the CPU's rules. Thus, you might get a segment of xoxoxoxo followed by a segment of xxxoxxxooo or oxoooxxoxxoooox - it just depends on which thread has the CPU when and for how long.

Originally Posted by jiml8 it just depends on which thread has the CPU when and for how long.

Hie.. yeah the code works giving random x and o outputs. could you please tell me how do i control the amount of time which each of the thread get so that i can control the x and o generation to get equal no. of x and o generation. i assume RTlinux is used for this. but how exactly should it be done?

Another query that i have is why is thread important while writing control algorithms. I understand FIFO is important link between RT and normal linux. but what is the main role of threads in such algos?

Thank you so much for your help.

Hi -

how do i control the amount of time which each of the thread get so that i can control the x and o generation to get equal no. of x and o generation. i assume RTlinux is used for this.

No! Absolutely *not*.

a) It's a mistake to think "the amount of time given each thread" corresponds to the exact number of "x's" and "o's" you happen to count at any given moment.

b) It's also a mistake to think that threads in a "real time OS" (be RT Linux, an embedded OS like Wind River, or even Windows CE) will give output that looks substantially different.

Basically, you need to assume that threads operate completely independent of one another. And realize if you want any kind of "order" between the threads, then *you* need to do it yourself. For example, if you want both threads to print exactly 10 characters, then set your loop counter at "10". Or if you want them to run in lockstep (an "x", then an "o" before then next "x"), then you get to use a semaphore or a mutex of some kind.

By all means, please look at the links dwhitney67 recommended.

Originally Posted by navderm Hie.. yeah the code works giving random x and o outputs. could you please tell me how do i control the amount of time which each of the thread get so that i can control the x and o generation to get equal no. of x and o generation. i assume RTlinux is used for this. but how exactly should it be done?

You can't. Period. The threads run independently of each other; you can't control the processor utilization. What you CAN do is block one thread or the other at certain points for certain reasons using a mutex (mutual exclusion semaphore).

Another query that i have is why is thread important while writing control algorithms. I understand FIFO is important link between RT and normal linux. but what is the main role of threads in such algos? Thank you so much for your help.

I am deploying a multi-threaded application right now. One thread talks to a piece of hardware and collects data from it. Another thread processes the data. A third thread ships certain of the data across the internet to another computer when asked to. A fourth thread routinely ships specific data to another process - either on the same computer or on a different one - based upon the results of the data processing.

If I do it in one big loop, it might look like this:

1. collect data
2. process data
3. do I send data across internet? If so, send it.
4. send processed data to other process.
repeat indefinitely.

But why should I wait for the data to be collected? Why not process the LAST batch of data that was collected, while collecting the NEXT batch of data to process?

So I split out a thread to collect data, and use mutexes to make sure that the proper data is ready before I try to process it. When the batch of data is ready, I do some quick things to clear the buffer the data was provided in, then tell the thread that collects data to go collect more data, The data processing loop then proceeds to process the last batch of data. Hence, collection and processing occur in parallel.

And the data going across the internet can go whenever it is ready. Why should I wait until I get to that point in the loop to send it? The data I am sending was ready to be sent before most of the processing that I did was performed. Further, why should any other activity wait while I send this data?

So another thread is split out to watch that internet port and send the data when asked. Again, mutexes control WHEN the data can be sent; only when it is ready and not when it is being altered.

And finally, when I send the data to the other process, I have to wait for it to respond. Why should any of these other activities have to wait on this other process? Only the thread that is sending the data needs to wait. So, I split out another thread to do that, and it doesn't even need mutexes to synchronize it; it just ships data as long as it has data to ship. However, I do use a signal to tell it that there is data to ship so that it waits quietly until it has something to do.

My first iteration of this program was one thread. Everything was in the big loop. It took about 60 milliseconds to get through one pass of that big loop.

Once I had all the logic worked out, I split it into threads. It now takes 16 milliseconds to get through the loop and do all the jobs - and most of that time is spent waiting for the data collection to complete.

That is why you use threads.

I'll try to implement that. i know it will take time to assimilate it completely but thank you so so so much for such a wonderful and easy to understand write up.

Hie.

Okie i understand that threads are really important for such algorithms. But the fact that they can't be controlled is problematic.
What i have to do is take in 4 inputs from analog device (a robot) with its position and force values from position and force sensors. This has to be converted via AD converter. Then my program has to control the actuator as precise 5KHz(.2ms) timing using RTlinux. This time should include AD, DA and control computation or else the system can't be controlled. there are some small calculations ( i haven't written the code as yet so wont be able to tell you the no. of lines exactly. I have worked in microcontrollers and hence have an idea that no. of lines do make a difference in how much time it takes to complete the computation. Is it the same way when working with RTLinux??) .
Now since this has to be in a precise time of 5KHz and i can't control when and when not the thread runs, how do i go about it?
Also it must be that if there are 4 threads and some threads happen to run in between, the freq. of 5KHz should not be hampered.

Originally Posted by paulsm4 Hi - b) It's also a mistake to think that threads in a "real time OS" (be RT Linux, an embedded OS like Wind River, or even Windows CE) will give output that looks substantially different.

On the other hand..as far as i found out about the RTlinux systems, if i use command:
pthread_wait_np()
after supplying it the command:
pthread_make_periodic_np()
i can make two different threads, one pointing the 'x' generation code and the other pointing the 'o' generation code , and both of them would run after a precise timing ...giving me that xoxoxoxo output.

Guyz please rectify me if i am wrong here.

Okie
here is one more problem...
i had a small program which was giving me output of xxxooooo.
say this was one of the output.
now since these threads cannot be controlled, the output may be xxxxxx for next 1 min also. In such a case, it means only single of the 3 or 4 available threads was being used by the CPU. If now i have three threads
1. take input from hardware
2. process the data
3. give output to hardware
if such a thing happens to the same program with these three threads, its in a big trouble.

On the other hand, if i create the same three threads in RTlinux, i would have to initiate all of them together, in the init_module(). This would be workable if i could make them run after a specified amount of time. but then... what is the use of RT then????

Please clarify this doubt...its hitting my brain like 10 Kg rock...

Currently since my previous query is unsolved to me, i am assuming that in the time frame that I require (.2 ms) all the threads will be used atleast 5 times each.
Now, if i have to send the data to my output port after every .2ms, should I use the time controlled call (i.e. MONOTONIC call) to only output thread or to all. I guess if i call the output thread after every .2ms, the controller should work fine since i am assuming each thread is executed atleast 5 times each.

Is it possible that i start with init_module() and yet be able to define some threads as ordinary threads and some in time defined RT threads??

Originally Posted by navderm On the other hand..as far as i found out about the RTlinux systems, if i use command: pthread_wait_np() after supplying it the command: pthread_make_periodic_np() i can make two different threads, one pointing the 'x' generation code and the other pointing the 'o' generation code , and both of them would run after a precise timing ...giving me that xoxoxoxo output. Guyz please rectify me if i am wrong here.

YOu can do that, but it is not generally the way you want to do it when you are trying to synchronize threads - which is what you are trying to do.

To synchronize, you use mutexes, status flags, waits, and signals. Basically, a mutex is a mutual exclusion lock which has the property that only one thread at a time can lock it. Any thread that tries to lock it when it is already locked will wait until it is unlocked.

Thus, if threada locks a mutex and threadb then tries to lock it, threadb will hang UNTIL threada releases the mutex. Thus do you synchronize threads.

In the example I gave earlier, there is a data collection thread and a data processing thread. Clearly, the data processing thread can't process the data until it is ready to be processed. So here is what happens.

The DC thread is told to collect data, so it immediately locks a mutex and, while the mutex is locked, it sets a dataready flag to say "data not ready". It then immediately unlocks the mutex and proceeds to collect data.

The DP thread comes along and is ready to process more data. So it locks the same mutex the DC thread was using, then checks the dataready flag. If the dataready flag says data is ready, it unlocks the mutex then goes ahead and starts processing.

If the dataready flag says data not ready, then - without unlocking the mutex - it drops into a wait on a mutex signal port. The act of dropping into this wait unlocks the mutex for as long as this thread is waiting. So now the DP thread is suspended.

While this is happening, the DC thread has been collecting data, and sooner or later it finishes. When it finishes, it locks the same mutex, then sets the dataready flag to say that data is ready, then sends a signal to the DP thread's wait port. It sends this signal regardless of whether the DP thread is waiting or not; it does not know if the DP thread is waiting and if the DP thread is not waiting, the signal is discarded. After sending this signal, it unlocks the mutex.

With the mutex still locked, the DC thread then checks a flag to see if it is to collect more data. If it is to do so, it unlocks the mutex and goes about doing it.

If it has not been told to collect more data, it drops into a wait on a mutex signal port, waiting for a signal from the DP thread (or from anyone else for that matter). Dropping into this wait automatically unlocks the mutex.

Back to the DP thread, which has been waiting. It receives the signal from the DP thread and wakes up - thus automatically re-locking the mutex. It checks the dataready flag, sees that data is now ready. It therefore unlocks the mutex and starts processing data.

The first processing it does has the effect of unloading the buffer that the DC thread placed the new data in. So, as soon as this unloading is completed, the DP thread locks the mutex, sets the "collect more data" flag, and sends a signal to the DC thread telling it to collect more data. The DP thread then unlocks the mutex and goes about its business of processing data.

The DC thread, which has been waiting, wakes up on the signal (thus immediately locking the mutex). It checks the collect more data flag, sees that it is to do so, clears the collect more data flag, sets the data not ready flag, unlocks the mutex, and sets about collecting data.

Thus, we have gone through a complete data collection/data processing cycle.

Note the emphasis on locking and unlocking the mutex before taking any action that manipulates the flags with which these two threads communicate. The purpose here is to ensure there are no race conditions - one thread accessing the flag while the other one is changing it.

Note also that the mutex signal ports allow me to keep either thread from running until the conditions necessary for it to run correctly are met. For the DP thread, it can't run until new data is available; for the DC thread, it can't run until the DP thread has emptied the buffer.

This is a real life example. For your sample program, you would have one thread write an O, then signal the other thread and then go to sleep on a mutex port. The other thread would write an X, signal the other thread and then go to sleep on a mutex port.

This would compel your program to write alternating X and O.

Look at these commands:

pthread_cond_signal(&adc_condition_ready);
pthread_cond_wait(&adc_condition_getdata,&adc_mutex);
pthread_mutex_lock(&adc_mutex)
pthread_mutex_unlock(&adc_mutex);

Note that I left my own mutex and port names in the commands, since I lifted them straight from my code.