Linux C++ help

[board Lizard]

I have to write a multi-threaded C++ program for linux and I have just one question.. what is a thread?

[EnvyEyes]

/ducks and runs for cover

[casey]

a thread is an execution context.

[board Lizard]

and what the hell does that mean?

[newport]

this is a joke isn't it ?

[board Lizard]

no, this really is not a joke. i honestly don't know what a thread is but i need to know by the 17th because that is when its due

[newport]

I presume its a project for school.

Why not just refer to your teacher, maybe you missed the class they were discussing threads in.

[board Lizard]

cause she's crazy and spent today's entire 2 hour 45 minute class talking about threads and if i go up to her and ask "what's a thread" she might just lose it and then i'll end up dead in a ditch somewhere with my pants unbuttoned

[bubbahlicious]

A multi-threaded app is one where, at the same time, the application is following mutliple-code paths concurrently.

What do I mean?

Imagine this program:

#include "foobar.h"
int main()
{
foo();
bar();
foobar();
return 0;
}

The thread of execution for this program is pretty simple - first in 'main()', then into 'foo()'. When 'foo()' returns, the thread of execution goes back out to 'main()'. The same for the next two methods - the thread of execution follows in and out of each called function, until it exits 'main()' entirely, at which point the program terminates.

Sometimes it's desirable to let your computer do something in the backround, such as wait for a network call to terminate. It's possible to fire off a new thread of execution (such as a thread that updates the UI) while the main thread is busy checking if the network call has finished yet. Once you start a second thread of execution, your app is 'multi-threaded'.

I've never done thread programming in Linux (once or twice in windows tho).

If you check the man pages on 'pthread_create', you should be able to get started.

[newport]

Maybe try reading and or researching on the www.

If you fail to understand it after that, you will have to go back to your teacher and ask for an explaination.

Maybe you should have asked the question this way...

Can anyone give me more information on threads ?
We learnt about it in school today and I didn't understand it.

[throx]

Threads are something you'll need to do a lot of reading on. It's not really possible to explain exactly what it is on a messageboard beyond what people have already said.

Read your text. Play around with a few examples. Most people take a few years to really understand threads properly, but the best advice I can give on them is not to use them unless there's absolutely no other choice and even then try as hard as you can not to use them. They'll find all sorts of fun ways to deadlock for you.

[Iam_Walrus]

Recently, I found that I had to do a lot of work with threads. Check this out (http://everquest.allakhazam.com/db/quest.html?quest=1258)

[cryptorad]

http://www.sbac.edu/aixdocs/aixprggd/genprogc/multi-thread_prg.htm

The OS is AIX.. but you can probably use what you learned in class to correlate it to your OS. Which I'm assuming is Linux based on your post.

g'luck

[mvern]

I found this site (http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html) helpful when I first started playing with pthreads.

[Roadkill]

Here's an example. This program will create two infinate loops running in seperate threads at the same time. Obviously you'll want to put some code into the "// do some stuff" area, preferably a way to get out of the loops. I had keyboard commands that would exit the program for example (a /quit at the console that I had created).

Also, I had to give the compiler the -lpthread option for this to work.


#include <pthread.h>

void *Thread_Function (void *pParam)
{
while(1)
{
// do some stuff
}
pthread_exit(NULL);
}


int main(int argc, char *argv[])
{
pthread_t test_thread;

pthread_create(&test_thread,NULL,Thread_Function,NULL);

while(1)
{
// do some stuff
}
}

[Jillian]

Originally posted by Iam_Walrus
Recently, I found that I had to do a lot of work with threads. Check this out (http://everquest.allakhazam.com/db/quest.html?quest=1258) lol yeah, I loved that the glowing bile makes the wurms holds a "visible" light source...

[Resiliant]

Why make it complicated?

A thread is a piece of program code that can be executed in parallel with other threads. A 'multi-threaded architecture' is an operating environment whrein more than one thread can be executing at the same time.

[Cryonic]

Problems with Mutexes

An important problem associated with mutexes is the possibility of deadlock. A program can deadlock if two (or more) threads have stopped execution or are spinning permanently. The simplest deadlock situation: thread 1 locks lock A, thread 2 locks lock B, thread 1 wants lock B and thread 2 wants lock A. Instant deadlock. You can prevent this from happening by making sure threads acquire locks in an agreed order (lock ordering). Deadlock can also happen if threads do not unlock mutexes properly.

Race conditions occur when multiple threads share data and at least one of the threads accesses the data without going through a defined synchronization mechanism (Nichols 203). This could result in erroneous results even in an inconsistent manner which makes race conditions particularly difficult to debug. Library calls outside of your program's control are common culprits. Make sure you take steps within your program to enforce serial access to shared file descriptors and other external resources. On most Solaris man pages, you can find out if your library call is safe to use in reentrant code. Towards the bottom of the man page, you will see Categories of MT Library Calls. MT Safe means that the function can be called concurrently from different threads. MT Hot are "fast" MT Safe functions (usually not found on man pages). MT Unsafe means that the function cannot be called concurrently. Alternative means that there are MT Safe equivalents (e.g. gethostbyname() and gethostbyname_r()).

Another problem with mutexes is that contention for a mutex can lead to priority inversion. A higher priority thread can wait behind a lower priority thread if the lower priority thread holds a lock for which the higher priority thread is waiting. This can be eliminated/reduced by limiting the number of shared mutexes between different priority threads.