Transfer data across thread borders

Question

3.00/5 (2 votes)

See more:

Hi experts,

this is for a semi-automatic hardware device test. User places the device to be tested ("the testee") within the apparatus.
Then User hits a button. It is the only button within this context. It's not on the keyboard but belongs to the apparatus. The button hit is being processed and finally reaches the application as an event.

The application core is a sequence of tasks. The easiest way to accomplish that would be to have some statements like

C#

Task0();
WaitForUserButton();
Task1("Foo", "Bar");
Task2(24);
WaitForUserButton();
Task3();

The interesting part is WaitForUserButton().
Prior to executing the next statement(s), User has to deal with the testee and then press his button to announce that the sequence may continue.

To manage the block-and-continue of the sequence, I used System.Threading.AutoResetEvent[^] this way:

C#

using System.Threading;
private AutoResetEvent _autoResetEvent = new AutoResetEvent(false);

void MyBase_ExternalButtonPressed()
{
    _autoResetEvent.Set();
}

private void WaitForUserButton()
{
    MyBase.ExternalButtonPressed += MyBase_ExternalButtonPressed;

    _autoResetEvent.WaitOne(TimeSpan.FromMilliseconds(100));

    MyBase.ExternalButtonPressed -= MyBase_ExternalButtonPressed;
}

Now I need to react on another event with such an event handler signature:

C#

public delegate void ParameterPackedDelegate(int foo);

I just don't see how to get that foo value into WaitForSomeEvent().

How can I attach data to AutoResetEvent.Set()?

Posted 30-Jan-12 2:42am

lukeer

Updated 30-Jan-12 23:26pm

v3

Add a Solution

Comments

Sergey Alexandrovich Kryukov 30-Jan-12 12:53pm

Please tag the language as well. What is that?

#using System.Threading;

looks weird.
--SA

lukeer 31-Jan-12 2:38am

This is my special, personal coding-in-C#-for-years-now-but-cannot-flee-my-C-roots-when-typing-in-forum-without-syntax-check language.

Changed it to plain C# for better understanding.

Sergey Alexandrovich Kryukov 31-Jan-12 12:01pm

:-)

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2012-01-30T07:03:00

Solution 1

You cannot attach any data to EventWaitHandle. I think you have no idea about the purpose of even wait handles. You code is a strange mixture of events thread synchronization primitives and and does not seem reasonable at all. Using "-=" operators on the invocation list of an event instance is usually a bad idea. One thing you should keep in mind is that .NET events and event wait handles have nearly nothing in common, they are completely different and unrelated concepts.

It's hard to help you as you did not really explain the goal of this activity.

Perhaps you will get some idea from my past solutions in response to other questions.

On event wait handles:
ManualResetEvent and AutoResetEvent in Thread[^],
pause running thread[^].

Using them for thread communication and synchronization with data — my Tips & Trick article where I introduce the blocking queue, with full source code and sample of the usage: Simple Blocking Queue for Thread Communication and Inter-thread Invocation[^].

See also more references on threading, my collections of links to my past solutions:
How to get a keydown event to operate on a different thread in vb.net[^],
Control events not firing after enable disable + multithreading[^].

—SA

Posted 30-Jan-12 7:03am

Sergey Alexandrovich Kryukov

Comments

lukeer 31-Jan-12 5:54am

> I think you have no idea about the purpose of even wait handles.
That is why I only use odd ones ;-)
The strange mixture stems from the unusual operation paradigma. Generally, one action is started by activating one UI element. Here, the only UI element (thee button) starts different actions depending on the context (current position in sequence).

> Using "-=" operators [..] is usually a bad idea.
Why is that?
Not using "-=" would inherently forbid using "+=" except for some initialization. Otherwise we would end up with an arbitrarily large number of event handlers attached to the event.

> [...] .NET events and event wait handles have nearly nothing in common.
Even though I'm just starting to use event wait handles, I'm fairly familiar with events. I'm fully aware that their only mutuality is linguistic.

> You cannot attach any data to EventWaitHandle
That's what I feared. So I will have to revert to
a) member variables, written by the event handler and read from the sequence or
b) some kind of state machine with enumerated steps, a variable to store last position in sequence and a rather large switch statement.

Both seem relatively ugly to me.
Any thoughts other than that?

Sergey Alexandrovich Kryukov 31-Jan-12 11:49am

OK, without explaining your paradigm I won't be able to give you a further advice. I'm not sure it's necessary, because the synchronized data exchange between threads is the well-known problem which has comprehensive solutions. One on them is the blocking queue I've mentioned.
--SA

Sergey Alexandrovich Kryukov 31-Jan-12 11:52am

The operation "-=" is bad because it assumes that both "-=" and "+=" are repeated many times. You can imagine how expensive are they if you know what they do. It's much better to have a Boolean flag and a check at the very beginning of an event handler like "HandlingAllowed". If not allowed, return immediately. This way you switch processing -- not processing.
--SA

Sergey Alexandrovich Kryukov 31-Jan-12 12:00pm

...large swithch statement? I have an article which you can read; and after that you will non need them:
http://www.codeproject.com/Articles/203453/Dynamic-Method-Dispatcher

About any other thoughts: 1) queue, see above; 2) I might need to learn about your paradigm and the ultimate goals of your application; 3) you need the holistic threading architecture, not just threads, and on top their data exchange and synchronization, so learn about synchronization first (there are many more primitives: lock, upgradable read-write lock, mutex, semaphore...), and the design threading from scratch.

--SA