| | |
My First Multi-Threaded Code! What Do You Think?
Please support our C++ advertiser: Intel Parallel Studio Home
Thread Solved |
•
•
Join Date: Oct 2008
Posts: 33
Reputation:
Solved Threads: 0
I need to know how i did? Any review will be appreciated...
C++ Syntax (Toggle Plain Text)
/**program description: * * this simple program represents * the basic concept of threads. * main() process will create a * thread that calculate numbers * while main() output the results. * main() and threadProcess() share * share data from a same memory. * threadProcess() add two numbers * and dump the result into totalNumber. * On the other hand, main() uses * totalNumber to output the result. * Thus, totalNumber is the shared scope. * To avoid collision, i used mutex. * */ #include <iostream> #include <windows.h> using namespace std; int totalNumber = 0; bool threadStarted = false; HANDLE mutexHandle = NULL; void threadProcess() { threadStarted = true; for (int i=0; i < 10; i++) { WaitForSingleObject(mutexHandle, INFINITE); cout<<"threadProcess() is calculating: "<<endl; totalNumber += i; //make thread procedure in same //speed as main() process Sleep(10); ReleaseMutex(mutexHandle); } } int main() { mutexHandle = CreateMutex(NULL, false, NULL); HANDLE threadHandle = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)threadProcess, NULL, 0, NULL); //let thread starts first - main() //somewhat starts faster than the //spwaned process while(!threadStarted) { } for(int i = 0; i < 10; i++) { WaitForSingleObject(mutexHandle, INFINITE); cout<<"main() is giving out solution: "<<endl; cout<<totalNumber<<endl; //make main() process run in same speed //with the created thread Sleep(10); ReleaseMutex(mutexHandle); } //wait for the thread to finish //in case its hanging around WaitForSingleObject(threadHandle, INFINITE); CloseHandle(mutexHandle); cin.get(); return 0; }
Last edited by f.ben.isaac; Apr 15th, 2009 at 1:14 am.
You should be pleased with your first attempt, it demonstrates threading nicely.
There are some criticisms I would make:
Your mutex isn't actually achieving much - totalNumber is only being updated by one thread. main() is just reading it, so no protection is necessary in this case. If you are using the mutex for synchronisation, well that isn't happening because each thread is releasing the mutex, then immediately trying to grab it again. You don't know which thread will get control.
What's the Sleep(10) for? If you are trying to ensure that control passes to the other thread it would be better placed after the ReleaseMutex() call. In any case, using Sleep() to try and synchronise threads is not a practical solution.
Just an idea, but why not try to implement this project using Events instead of a mutex. You could have an event for each thread to indicate when it has completed it's loop. Each thread checks the other thread's Event and proceeds when signalled. That would give you fully syncronised and more robust code (and a bit more practice
).
There are some criticisms I would make:
Your mutex isn't actually achieving much - totalNumber is only being updated by one thread. main() is just reading it, so no protection is necessary in this case. If you are using the mutex for synchronisation, well that isn't happening because each thread is releasing the mutex, then immediately trying to grab it again. You don't know which thread will get control.
What's the Sleep(10) for? If you are trying to ensure that control passes to the other thread it would be better placed after the ReleaseMutex() call. In any case, using Sleep() to try and synchronise threads is not a practical solution.
Just an idea, but why not try to implement this project using Events instead of a mutex. You could have an event for each thread to indicate when it has completed it's loop. Each thread checks the other thread's Event and proceeds when signalled. That would give you fully syncronised and more robust code (and a bit more practice
). •
•
•
•
Originally Posted by MrSpigot
main() is just reading it, so no protection is necessary in this case.
Agreed on not using Sleep(). It's a useless function: wait for events to happen, don't guess how long such and such is going to take, and put that time in Sleep().
•
•
•
•
That's wrong, almost 100% sure, couldn't make sure with google, but it's just 2 threads trying to access the same memory: doesn't matter if they read or write, both will lead to errors.
There are 2 threads here. One reads and writes (ie an addition), the other just reads. Two threads can indeed access the same memory quite happily (ok there might be some exceptions for custom embedded systems, but we're talking general purpose computers here). You have to remember that the operations in separate threads are not actually happening simultaneously, they are sequential at the hardware level and will not generate bad/corrupted data.
The write operation is atomic, you can't get half a write operation, so the read from the other thread will either get the value before or after the write. In this case it doesn't matter which it gets.
Of course, you do need to be aware of the operations you perform. Reading/writing a database in this way would not necessarily be atomic and possibly not safe.
Where would a good place be to learn more about multithreading? I don't think there is much at www.cpluplus.com. Any suggestions on libraries/tutorials? Thanks!
MrSpigot was 100% right, my bad. You don't need mutexes to write and read from one variable at the same time.
Tested with:
Tested with:
cpp Syntax (Toggle Plain Text)
#include <iostream> #include <windows.h> using namespace std; int victim = 10; void thread() { for(int n = 0; n < 99999999; n++){ victim = n; } } int main() { HANDLE thread1 = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thread, NULL, 0, NULL); HANDLE thread2 = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thread, NULL, 0, NULL); HANDLE thread3 = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thread, NULL, 0, NULL); WaitForSingleObject(thread1, INFINITE); WaitForSingleObject(thread2, INFINITE); WaitForSingleObject(thread3, INFINITE); return 0; }
•
•
•
•
Well I would appreciate you backing up a statement like that!
There are 2 threads here. One reads and writes (ie an addition), the other just reads. Two threads can indeed access the same memory quite happily (ok there might be some exceptions for custom embedded systems, but we're talking general purpose computers here). You have to remember that the operations in separate threads are not actually happening simultaneously, they are sequential at the hardware level and will not generate bad/corrupted data.
The write operation is atomic, you can't get half a write operation, so the read from the other thread will either get the value before or after the write. In this case it doesn't matter which it gets.
Of course, you do need to be aware of the operations you perform. Reading/writing a database in this way would not necessarily be atomic and possibly not safe.
It's a wrong statement even for home desktop compiters with multicore processors.
>...and will not generate bad/corrupted data
It's a wrong statetement, especially referred to compound objects.
>The write operation is atomic, you can't get half a write operation...
It's a wrong statement, especially for string data, but for compound objects too. As usually, regular microprocessors provide atomic write operations only for 32-bit aligned words.
>In this case it doesn't matter which it gets
It's a wrong statement. How about corrupted program logic and erratical behaviour?..
>Reading/writing a database in this way would not necessarily be atomic and possibly not safe.
Most of modern database engines provide implicit transactions on SQL statement level so possibly it would be atomic...
Hmm...
•
•
•
•
>You have to remember that the operations in separate threads are not actually happening simultaneously
It's a wrong statement even for home desktop compiters with multicore processors.
>...and will not generate bad/corrupted data
It's a wrong statetement, especially referred to compound objects.
>The write operation is atomic, you can't get half a write operation...
It's a wrong statement, especially for string data, but for compound objects too. As usually, regular microprocessors provide atomic write operations only for 32-bit aligned words.
>In this case it doesn't matter which it gets
It's a wrong statement. How about corrupted program logic and erratical behaviour?..
>Reading/writing a database in this way would not necessarily be atomic and possibly not safe.
Most of modern database engines provide implicit transactions on SQL statement level so possibly it would be atomic...
Hmm...
•
•
•
•
Originally Posted by MrSpigot
I accept all that you're saying there, and good point about the multi-core processors, though even they would not cause a problem in this case.
![]() |
Similar Threads
- segmentation fault (C++)
- Multi threads ... ??? (Python)
- Multi Thread Help (Java)
- Problem with linked list in multi-threaded C program (C)
- What is the use of #define _REENTRANT in my code? (C++)
- http://code.google.com/ -- Introduced for API (IT Professionals' Lounge)
Other Threads in the C++ Forum
- Previous Thread: random-access files
- Next Thread: c++ problem need help pls
| Thread Tools | Search this Thread |
api array based beginner binary c++ c/c++ calculator char char* class classes code compile compiler console conversion count delete deploy desktop directshow dll download dynamic dynamiccharacterarray email encryption error file forms fstream function functions game givemetehcodez google graph gui homeworkhelp homeworkhelper iamthwee ifstream input int integer java lib linkedlist linker linux list loop looping loops map math matrix memory news numbertoword output parameter pointer problem program programming project proxy python random read recursion recursive reference return rpg sorting string strings struct temperature template templates test text text-file tree unix url variable vector video visual visualstudio win32 windows winsock wordfrequency wxwidgets






