Jump to content

  • Log In with Google      Sign In   
  • Create Account


Win32 event and thread API question


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Laval B   Crossbones+   -  Reputation: 4660

Like
0Likes
Like

Posted 29 May 2012 - 10:13 AM

Hello everyone

I ran into a little problem using win32 event api. I have threads that are blocked on an event. When some job is ready to be executed, the event is signaled (using SetEvent). Jobs are placed in a shared queue.

According to Microsoft documentation, one of the waiting threads will wake and the event will be reset (autoreset event). The problem i have is that if no thread is wating because they are all busy, the event will be lost and when they go back waiting, none of them will ever know about the new job.

Is there a way to solve that problem ?
We think in generalities, but we live in details.
 
Alfred North Whitehead

Sponsor:

#2 frob   Moderators   -  Reputation: 20085

Like
1Likes
Like

Posted 29 May 2012 - 11:27 AM

A missed event is a common problem when not using a lock acquisition system.

The article "Solving 11 likely problems in your multithreaded code" discusses it about 3/4 of the way through, and includes links to several other articles that provide solutions.

Multithreading is hard to do correctly. There is no tutorial you can use, no block of code you can copy, that will give you solid concurrent code. You need to have a complete mindset of concurrency that is used through the entire code base.
Check out my personal indie blog at bryanwagstaff.com.

#3 Laval B   Crossbones+   -  Reputation: 4660

Like
1Likes
Like

Posted 29 May 2012 - 11:42 AM

Multithreading is hard to do correctly. There is no tutorial you can use, no block of code you can copy, that will give you solid concurrent code. You need to have a complete mindset of concurrency that is used through the entire code base.


Yes, i realize that and this is what i'm trying to get. Thank you very much for the reference.
We think in generalities, but we live in details.
 
Alfred North Whitehead

#4 Laval B   Crossbones+   -  Reputation: 4660

Like
1Likes
Like

Posted 29 May 2012 - 12:21 PM

I'm now using a semaphore instead of an event. That way, even if the thread is processing, the semaphore still gets incremented and when it calls WaitForSingleObject again, if the count isn't back to zero, it will process otherwise, it will go back to sleep.

Edited by Laval B, 29 May 2012 - 12:22 PM.

We think in generalities, but we live in details.
 
Alfred North Whitehead




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS