thread problem

[Dirk Reske]

Hello,

if habe the class "receiver" which reads data out of a stream.

that the application doesn't get blocket the class starts the function
"readData" in its own thread.

but I want the function for each incoming data to call a function in in
the receiver thread, not in its own!

P.S. the receiver class doesn't run in an UI thread, so Control.Invoke
doesn't work!

hope, you understand...I'm german

 

[Jon Skeet]

It sounds like you're after a producer/consumer queue.

See http://www.pobox.com/~skeet/csharp/threads/deadlocks.shtml
(from half way down the page).

Jon

 

[Dirk Reske]

I think, this is not, what I'm looking for.
example:

class receiver
{
private delegate void StartDelegate(some params);
private StartDelegate Start;

public receiver()
{
Start = new StartDelegate(readData);
Start.BeginInvoke(some params,null,null);
}

private void Callback(param)
{
//work with the data
}

private void readData(some params)
{
while(true)
{
//here is the main stuff to read the data

//is it possible to call the callback in the parent
//thread??
Callback(param);
}
}
}

 

[Jon Skeet]

//is it possible to call the callback in the parent

//thread??

The "parent thread" would have to be waiting for you to ask it to do
something.

I very much suspect that you do want at least one producer/consumer
queue,
possibly more.

Jon

 

[Dirk Reske]

yes, but how do I signal the parent thread, that there is data?

when I run a loop in it, which checks, if there is any, it get blocket,
doesn't it?

I think of a way, the worker thread fires up an event in the main
thread!

like it works in UI thread. with Control.Invoke...
there I invoke a method in another thread...

 

[Jon Skeet]

yes, but how do I signal the parent thread, that there is data?

By adding something to the queue - that pulses the monitor
appropriately.

when I run a loop in it, which checks, if there is any, it get blocket,
doesn't it?

Yes. So you want a thread which is just waiting for those events. If
you're doing other things in the thread which is meant to react to
the events, it's not going to react until it notices the event.

I think of a way, the worker thread fires up an event in the main
thread!

like it works in UI thread. with Control.Invoke...
there I invoke a method in another thread...

All that effectively does is put a delegate in a queue - which the UI
thread picks up and runs. The message pump is effectively a
producer/consumer queue.

Jon

 

[Dirk Reske]

All that effectively does is put a delegate in a queue - which the UI

thread picks up and runs. The message pump is effectively a
producer/consumer queue.

yes, but what I'm not understand is, how does the thread knows when there is
something in the queue...
perhaps some commented example, when this is not to much.

dirk

 

[Jon Skeet [C# MVP]]

yes, but what I'm not understand is, how does the thread knows when there is
something in the queue...
perhaps some commented example, when this is not to much.

Using Monitor.Wait. Please reread the article I linked to earlier - it
explains it all in detail.

 

[Dirk Reske]

I think, I've understood now...

the "main" thread is the consumer....it wait's for data from the worker
thread...
the worker thread reads the data...and signals the main thread, wenn data is
available!
right?

but while the time, the main thread waits for this signal...it gets blocked!
and this is the thing I don't want!

 

[Jon Skeet [C# MVP]]

I think, I've understood now...

the "main" thread is the consumer....it wait's for data from the worker
thread...
the worker thread reads the data...and signals the main thread, wenn data is
available!
right?

That's exactly right.

but while the time, the main thread waits for this signal...it gets blocked!
and this is the thing I don't want!

Then you need more threads - or you need to make the main thread only
process the data when it's "free". (That's easy enough to do, but a
somewhat different question.)