By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,763 Members | 1,439 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,763 IT Pros & Developers. It's quick & easy.

simple question about event

P: n/a
Hi
I have an event that receives data from RS port

rs.DataReceived += new SerialDataReceivedEventHandler(rs_DataReceived);

I need to block raising an event when the previous one has not lelft yet.

RS port is receiving very fast the portions of data. When first data
receives, user is asked to do something with this data. Then each another
raise of this event is dooing the same what user did with this data.
The problem is when first raise of event finishes, i have already full
buffer. And event is raised
Or maybe there is a way to clear the buffer....

Any help would be appreciated
May 16 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Hi,

This is an example of Producer-Consumer escenario. you can google for
several way to solve this.
--
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"PiotrKolodziej" <pi*************@gmail.com> wrote in message
news:9e***************************@news.chello.pl. ..
Hi
I have an event that receives data from RS port

rs.DataReceived += new SerialDataReceivedEventHandler(rs_DataReceived);

I need to block raising an event when the previous one has not lelft yet.

RS port is receiving very fast the portions of data. When first data
receives, user is asked to do something with this data. Then each another
raise of this event is dooing the same what user did with this data.
The problem is when first raise of event finishes, i have already full
buffer. And event is raised
Or maybe there is a way to clear the buffer....

Any help would be appreciated

May 16 '06 #2

P: n/a
I tend to avoid multithreading when I can, just because it complicates
everything, but in this case I don't see how you can get around it.

The problem, as I understand it, is that you have no idea how long it's
going to take the user to make a decision about what to do with the
data, and so it's not really an option to wait for a response before
you react to other events coming in from the RS port.

Therefore, you have little choice but to change your architecture.
Basically, you should be stacking up data coming in from the RS port in
a queue of some kind while the user is making up his or her mind as to
what to do. Whenever you get an event from the RS port you should
immediately grab the data from the buffer, stick it in some object, and
then queue that object for processing.

When the first piece of data arrives, the program must ask the user
what to do with it, but you can't ask on the same thread on which
you're reading from the RS port, because you can't afford to have the
question to the user blocking you while more data is coming in.

This means (to me) that somehow you have to be reading the RS port from
a background thread, while you ask the user what to do on the main UI
thread.

When the user finally responds, you then process all of the data in the
queue and then wait for more to be queued. I assume that this would be
a yet a third thread, that would simply read from the queue and deal
with the data, then when the queue is empty go to sleep and wait to be
woken up when there is more data in the queue.

At the very least you need something, like a queue, between the RS port
read and the processing to be done, so that data can build up while the
user is deciding what to do and nothing will be lost.

May 16 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.