Events

[demian]

Hi!.

I have a thread and a function that pass some value to the thread. The function must wait to pass the value until the thread is not longer occupied, (or for a milliseconds), and then the function must wait again for the work that make the thread with the value and finally the function return.
I know that I can fix my problem with events, that's the question, with C++ I use CreateEvent(), SetEvent(), WaitForSingleObject(), ResetEvent() but, How could I make that in C#?.
How can I create an event such a "ThreadFree", "ThreadOccupied", etc.

Thank you.

[TheCPUWizard]

Easiest solution is to use delegates.

[andy248]

I'm afraid that delegates will not work for synchronizing threads. In .NET, there are some classes that can be used for synchronization purposes. Just look for these keywords in the documentation:
- Thread
- AutoResetEvent
- WaitHandle
With these, you can implement thread synchronization based on system events.

[TheCPUWizard]

Andy, I did not meen to imply the delegates "synchronize" threads, but they are a solution (or at least a part of one) for the original posters question.

If I have a thread that needs to know (not necessarily wait, just need to know) when another thread has completed an operation [not that the thread itself has completed], the use of a delegate will provide a viable solution with minimal coupling between the entities.

It is important to realize that the "callback" will execute in the contxt of the calling thread (ie the thread that just finished the work and not the thread that needs to know that the work is finished).

If you use one of the synchronization objects that you refered to with one thread setting the "event" (in its source code) and the other thread waiting on the "event" (in its source code), you have created much tighter coupling between the parts than is necessary or desirable.

Consider what happens if you would like to re-use the "worker" code in a different location, but with a totally different form of synchronization......

If the worker code merely invokes a delegate the implementation of the "handling" code is going to live in the thread that wants the notification (again it will execute in the "worker" thread!). The desired synchronization method can then be implemented in that source code.

[andy248]

Hmmh, we are probably moving away from the original question, but let's have this discussion anyway...

Yes, I totally agree with your comments regarding the level of coupling, especially with future extensions in mind. But let me explain my motivation for recommending thread synchronization features:

The problem if my threads are communicating via delegates is that the event handling code lives in the context of the event raising thead. You mentioned this in your post.

Consider the worker thread raising an event. Some client thread catches this event, and then does some lengthy operation based on this notification. Control will not return to the event raising thread until this lengthy operation has been completed. It can't, because the event handler is operating in the context of the event raising thread, as mentioned by you.

There are many scenarios where the event raising thread needs to regain control immediately after raising the event, and for these scenarios I would still consider AutoResetEvents and WaitHandles.

In some way, it reminds me of the difference between PostMessage and SendMessage...

[TheCPUWizard]

Want to make sure the client does not take too long (this would be a requirement of the worker)...simply use an Async invokation of the delegate.

Now you have encapsulated the requirement where it belongs.....


:D