Is there a way to pass multiple parameters to the thread, instead of using global values?
Thank you.
Is there a way to pass multiple parameters to the thread, instead of using global values?
Thank you.
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
Create a struct containing all the information you want to pass.
Create an instance of that struct(*), fill it with information, and then pass a pointer to the whole thing to the thread.
(*) you have to make sure that the scope of the memory allocated lasts at least as long as the thread being created. For example, pointers to local variables almost never work.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Can you please give me an example...(*) you have to make sure that the scope of the memory allocated lasts at least as long as the thread being created. For example, pointers to local variables almost never work.
Last edited by Devil Panther; 12-02-2006 at 01:38 PM.
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
Yeah, use malloc
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Ok, but how can I be sure they don't get mixed between different threads?
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
Because each thing returned by malloc is guaranteed to be a unique object which will last until you explicitly call free.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
use different mallocs for different threads...Originally Posted by Devil Panther
PS. And as I remember it is not recomended to call the CreateThread directly
use beginthreadex - it wraps the windows call and provides some additional initialization needed for correct work of the C/C++ runtime libraries
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Here's what MSDN says about the issue.
A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multi-threaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.
Last edited by Ken Fitlike; 12-03-2006 at 05:48 AM. Reason: use [quote][/quote] tags for text to ensure it wraps
I'm not sure this will work for me.Originally Posted by Salem
Here is what I'm trying to do:
I'm scanning a directory for it's files.
Once the file is found I would like to open a new thread to process it.
How can I use malloc if the name of the variable is the same?
Where should I allocate the memory, inside the new thread?
thanks.
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
Something like that maybe:
Code:while(...) { int* a = malloc(sizeof *a); long h; if(a) { unsigned thread_id; *a = rand(); //fill with something useful h = _beginthreadex(NULL, 0, thread_proc, (void*)a, 0, &thread_id); if(h != 0) CloseHandle((HANDLE)h); //we not interested in the return value of the thread } } unsigned __stdcall thread_proc( void * param) { int value = 0; if(param) value = *(int*)param; //do processing free(param); return 0; }
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Oh... Using the address of the newly allocated variable.
Got it, thank you.
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
[strike]vart's example may kill the thread before it gets a chance to run (and free memory).[/strike](See below) (beginthread also returns uintptr_t.)
Also, pthreads are your friend.
That makes the example worth it...*a = rand(); //fill with something useful
Last edited by Cactus_Hugger; 12-04-2006 at 12:33 AM.
long time; /* know C? */
Unprecedented performance: Nothing ever ran this slow before.
Any sufficiently advanced bug is indistinguishable from a feature.
Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
The best way to accelerate an IBM is at 9.8 m/s/s.
recursion (re - cur' - zhun) n. 1. (see recursion)
Yeah? And how exactly?vart's example may kill the thread
MSDN says:
Closing a thread handle does not terminate the associated thread.
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
/me retracts he previous statement as steathily as possible.
That seems illogical, but MSDN does say it... my mistake. (CBoard needs strikeout.)
Now you see why pthreads are my friend. All this nonsense between beginthread, beginthreadex, and family is driving me nuts.
Last edited by Cactus_Hugger; 12-04-2006 at 12:34 AM.
long time; /* know C? */
Unprecedented performance: Nothing ever ran this slow before.
Any sufficiently advanced bug is indistinguishable from a feature.
Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
The best way to accelerate an IBM is at 9.8 m/s/s.
recursion (re - cur' - zhun) n. 1. (see recursion)
It is interesting (at least for me) to note that you can easily pass this as the parameter, and connect the thread back to an object.
Oh yeah, MSDN says this about CloseHandle and threads.Code:m_hThread = ::CreateThread( 0, 0, /* ( DWORD ( WINAPI * )( LPVOID ) ) */ run, LPVOID(this), 0, &m_dwThreadID ); } /* static */ DWORD WINAPI foo::run( LPVOID vthis ) { foo * fthis = reinterpret_cast< foo * >( vthis ); return fthis->run(); } DWORD foo::run( void ) { // Do yr stuff with foo }
>> Closing a thread handle does not terminate the associated thread. To remove a thread object, you must terminate the thread, then close all handles to the thread.
Last edited by Tonto; 12-04-2006 at 12:41 AM.