Passing data to running thread
-
Hi. It looks like this: there is a worker thread, which just runs and there is a button, which when clicked, should send some data to this worker thread. And now i am thinking, how this can be done. First off, i am a little bit skeptical about pipes and global variables. More real-life example would be something like this: 1. There is a thread. 2. There is a dialog window which accepts files. When file is dropped on this dialog window, thread should be notified that new file has been dropped and receive an open handle to this file and a file name. I was thinking about user mode APC but actually dont know if using this i can communicate with a thread or change its context, influence its variables, access its variables, modify them and use them - that would be great but the only thing i did so far with APC is terminating a thread. Another scenario i can thinks of, is having some global structure, update it time to time, signal thread so it will know that our struct has been filled with some new info so the thread can grab it - but yet again, global variables - not so good. Is there some "clear" and nice way of doing this? Thanks
011011010110000101100011011010000110100101101110 0110010101110011
-
Hi. It looks like this: there is a worker thread, which just runs and there is a button, which when clicked, should send some data to this worker thread. And now i am thinking, how this can be done. First off, i am a little bit skeptical about pipes and global variables. More real-life example would be something like this: 1. There is a thread. 2. There is a dialog window which accepts files. When file is dropped on this dialog window, thread should be notified that new file has been dropped and receive an open handle to this file and a file name. I was thinking about user mode APC but actually dont know if using this i can communicate with a thread or change its context, influence its variables, access its variables, modify them and use them - that would be great but the only thing i did so far with APC is terminating a thread. Another scenario i can thinks of, is having some global structure, update it time to time, signal thread so it will know that our struct has been filled with some new info so the thread can grab it - but yet again, global variables - not so good. Is there some "clear" and nice way of doing this? Thanks
011011010110000101100011011010000110100101101110 0110010101110011
Short answer: You'll use WaitForSingleObject[^] to wait on an event, critical section, or so (depending on your scenario). The event should be triggered (SetEvent[^]) when a file is dropped that needs processing.
csrss wrote:
Is there some "clear" and nice way of doing this?
If you're using MFC, you could use an UI thread[^] (the name is weird - an UI thread need not necessarily be associated with an UI). If you do it, you'll just post a message to the message pump of the thread and the thread will pick it off its queue and process it. This is an easy way, but it is an overkill if the thread is just supposed to do only one type of job (as opposed to doing different things based on the message posted to its queue).
"Real men drive manual transmission" - Rajesh.
-
Short answer: You'll use WaitForSingleObject[^] to wait on an event, critical section, or so (depending on your scenario). The event should be triggered (SetEvent[^]) when a file is dropped that needs processing.
csrss wrote:
Is there some "clear" and nice way of doing this?
If you're using MFC, you could use an UI thread[^] (the name is weird - an UI thread need not necessarily be associated with an UI). If you do it, you'll just post a message to the message pump of the thread and the thread will pick it off its queue and process it. This is an easy way, but it is an overkill if the thread is just supposed to do only one type of job (as opposed to doing different things based on the message posted to its queue).
"Real men drive manual transmission" - Rajesh.
Thanks. Well, i need this for a simple test project - i did already something like this UI Thread, so here is nice and simple solution :)
1. Parameters
struct PARAMS
{
int Val1;
int Val2;
};- Thread
DWORD __stdcall Thread(LPVOID lpParam)
{
MSG Message;
while(true)
{
::GetMessage(&Message, NULL, 0, 0);
switch(Message.message)
{
case SOMETHING:
// .......... do something
// Message.lParam will contain a pointer
PARAMS *p = (PARAMS*)Message.lParam;
}
}
}- Notification
PARAMS *p = new PARAMS;
p->Val1 = ...
::PostThreadMessage(m_dwMyThread, SOMETHING, NULL, (LPARAM)p);011011010110000101100011011010000110100101101110 0110010101110011
-
Thanks. Well, i need this for a simple test project - i did already something like this UI Thread, so here is nice and simple solution :)
1. Parameters
struct PARAMS
{
int Val1;
int Val2;
};- Thread
DWORD __stdcall Thread(LPVOID lpParam)
{
MSG Message;
while(true)
{
::GetMessage(&Message, NULL, 0, 0);
switch(Message.message)
{
case SOMETHING:
// .......... do something
// Message.lParam will contain a pointer
PARAMS *p = (PARAMS*)Message.lParam;
}
}
}- Notification
PARAMS *p = new PARAMS;
p->Val1 = ...
::PostThreadMessage(m_dwMyThread, SOMETHING, NULL, (LPARAM)p);011011010110000101100011011010000110100101101110 0110010101110011
csrss wrote:
DWORD __stdcall Thread(LPVOID lpParam)
{
MSG Message;
while(true)
{
::GetMessage(&Message, NULL, 0, 0);
switch(Message.message)
{
case SOMETHING:
// .......... do something
// Message.lParam will contain a pointer
PARAMS *p = (PARAMS*)Message.lParam;
}
}
}The code is doing a GetMessage within an infinite loop, which doesn't look good to me. I recommend that you have your thread code wait on an event instead, and set that event from outside the thread when the thread needs to get to work.
"Real men drive manual transmission" - Rajesh.
-
csrss wrote:
DWORD __stdcall Thread(LPVOID lpParam)
{
MSG Message;
while(true)
{
::GetMessage(&Message, NULL, 0, 0);
switch(Message.message)
{
case SOMETHING:
// .......... do something
// Message.lParam will contain a pointer
PARAMS *p = (PARAMS*)Message.lParam;
}
}
}The code is doing a GetMessage within an infinite loop, which doesn't look good to me. I recommend that you have your thread code wait on an event instead, and set that event from outside the thread when the thread needs to get to work.
"Real men drive manual transmission" - Rajesh.
I agree, this could end up using a lot of processor time doing nothing.
-
csrss wrote:
DWORD __stdcall Thread(LPVOID lpParam)
{
MSG Message;
while(true)
{
::GetMessage(&Message, NULL, 0, 0);
switch(Message.message)
{
case SOMETHING:
// .......... do something
// Message.lParam will contain a pointer
PARAMS *p = (PARAMS*)Message.lParam;
}
}
}The code is doing a GetMessage within an infinite loop, which doesn't look good to me. I recommend that you have your thread code wait on an event instead, and set that event from outside the thread when the thread needs to get to work.
"Real men drive manual transmission" - Rajesh.
GetMessage blocks until there's a message, so it's not bad like using PeekMessage right? :)
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Hi. It looks like this: there is a worker thread, which just runs and there is a button, which when clicked, should send some data to this worker thread. And now i am thinking, how this can be done. First off, i am a little bit skeptical about pipes and global variables. More real-life example would be something like this: 1. There is a thread. 2. There is a dialog window which accepts files. When file is dropped on this dialog window, thread should be notified that new file has been dropped and receive an open handle to this file and a file name. I was thinking about user mode APC but actually dont know if using this i can communicate with a thread or change its context, influence its variables, access its variables, modify them and use them - that would be great but the only thing i did so far with APC is terminating a thread. Another scenario i can thinks of, is having some global structure, update it time to time, signal thread so it will know that our struct has been filled with some new info so the thread can grab it - but yet again, global variables - not so good. Is there some "clear" and nice way of doing this? Thanks
011011010110000101100011011010000110100101101110 0110010101110011
You don't really need to "pass data to a thread", as all threads in a process have access to the same data. I typically use a semaphore to signal the worker thread when there's a job to do. The "jobs" are queued in a collection of some sort, and whenever a job is queued, the semaphore's count is incremented, setting its state to signaled. The worker thread waits on the semaphore and pops a job off the queue (don't forget to synchronize access to the collection with a critical section!) and processes it any time the semaphore is signaled. That's for a single worker thread...If I need a pool of worker threads, I'll use an I/O completion port instead....it does all the above and saves writing alot of thread plumbing code.
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
GetMessage blocks until there's a message, so it's not bad like using PeekMessage right? :)
Mark Salsbery Microsoft MVP - Visual C++ :java:
It's not as bad, but it certainly looks clumsy to me. The op needs to just use one of the several ways of thread synchronisation. :) Also, will there be a message queue associated with the thread? (note that the OP is calling it from within the worker thread).
"Real men drive manual transmission" - Rajesh.
-
You don't really need to "pass data to a thread", as all threads in a process have access to the same data. I typically use a semaphore to signal the worker thread when there's a job to do. The "jobs" are queued in a collection of some sort, and whenever a job is queued, the semaphore's count is incremented, setting its state to signaled. The worker thread waits on the semaphore and pops a job off the queue (don't forget to synchronize access to the collection with a critical section!) and processes it any time the semaphore is signaled. That's for a single worker thread...If I need a pool of worker threads, I'll use an I/O completion port instead....it does all the above and saves writing alot of thread plumbing code.
Mark Salsbery Microsoft MVP - Visual C++ :java:
Hey Mark. I have never actually dealt with semaphores before, mainly events in a regular fashion as well as mutexes and now IOCP :D Currently just needed some quick and dirty solution for this test project of mine, because it will land in a recycle bin as soon as i'll figure a couple of things out - just needed to smuggle pair of pointers here and there though ;) Anyways, thanks for a hints - will probably need that in near future.
011011010110000101100011011010000110100101101110 0110010101110011
-
It's not as bad, but it certainly looks clumsy to me. The op needs to just use one of the several ways of thread synchronisation. :) Also, will there be a message queue associated with the thread? (note that the OP is calling it from within the worker thread).
"Real men drive manual transmission" - Rajesh.
-
Hi. It looks like this: there is a worker thread, which just runs and there is a button, which when clicked, should send some data to this worker thread. And now i am thinking, how this can be done. First off, i am a little bit skeptical about pipes and global variables. More real-life example would be something like this: 1. There is a thread. 2. There is a dialog window which accepts files. When file is dropped on this dialog window, thread should be notified that new file has been dropped and receive an open handle to this file and a file name. I was thinking about user mode APC but actually dont know if using this i can communicate with a thread or change its context, influence its variables, access its variables, modify them and use them - that would be great but the only thing i did so far with APC is terminating a thread. Another scenario i can thinks of, is having some global structure, update it time to time, signal thread so it will know that our struct has been filled with some new info so the thread can grab it - but yet again, global variables - not so good. Is there some "clear" and nice way of doing this? Thanks
011011010110000101100011011010000110100101101110 0110010101110011
looking...