Problem with events

[danger]

I everybody, first of all sorry for my poor english. I have a problem
with an event that is generated more times very quickly so the
function subscribed doesn't finish his work. What can i do in order to
complete the work of the function before a new event is generated?
I have choosen two options:

1) Put the body of function inside a lock statement (i think is a
really bad idea)
2) Put every data generated with the event inside a list and a
separated thread manage the various operations of the data of that
list.

Does someone have better solutions?

Thanks you
Federico

 

[Jon Skeet [C# MVP]]

I everybody, first of all sorry for my poor english. I have a problem
with an event that is generated more times very quickly so the
function subscribed doesn't finish his work. What can i do in order to
complete the work of the function before a new event is generated?
I have choosen two options:

1) Put the body of function inside a lock statement (i think is a
really bad idea)
2) Put every data generated with the event inside a list and a
separated thread manage the various operations of the data of that
list.

Does someone have better solutions?

You'll need to give us more information. What's firing these events?
Is it coming in from different threads?

Option 2 sounds like a classic producer/consumer queue - you generate
work in one thread (or potentially many) and another thread (or again,
potentially many if there are no side-effects and dependencies) goes
through and processes that work. That's certainly a very valid
approach in many cases.

Jon

 

[luukas9]

I everybody, first of all sorry for my poor english. I have a problem
with an event that is generated more times very quickly so the
function subscribed doesn't finish his work. What can i do in order to
complete the work of the function before a new event is generated?
I have choosen two options:

1) Put the body of function inside a lock statement (i think is a
really bad idea)
2) Put every data generated with the event inside a list and a
separated thread manage the various operations of the data of that
list.

Does someone have better solutions?

Thanks you
Federico

Puedes explicarlo también en castellano? Así te puedo echar un cable

 

[Oddball]

You'll need to give us more information. What's firing these events?
Is it coming in from different threads?

Option 2 sounds like a classic producer/consumer queue - you generate
work in one thread (or potentially many) and another thread (or again,
potentially many if there are no side-effects and dependencies) goes
through and processes that work. That's certainly a very valid
approach in many cases.

Jon

Jon is, unsuprisingly enough having had a look through these forums,
on the ball. Unless the rapid firing is caused by the uncompleted
event handler (some sort of timer going on, which will build into a
crescendo if you stack multiple jobs causing eChina Syndrome) all you
really need to do is queue up the work jobs and handle them sensibly
and timelily... umm... in good time.

Try looking at the MS CCR (http://msdn2.microsoft.com/en-gb/robotics/
default.aspx) if you want a fancy pants solution to this problem.
Threads made easy (for a given subset of thread tasks, massive joins
not included, please read the small print). Don't be put off by the
fact that it says 'Robotics' all over it - that's just the weird
implementation MS have chosen for this awsome extension.

 

[Jon Skeet [C# MVP]]

Try looking at the MS CCR (http://msdn2.microsoft.com/en-gb/robotics/
default.aspx) if you want a fancy pants solution to this problem.
Threads made easy (for a given subset of thread tasks, massive joins
not included, please read the small print). Don't be put off by the
fact that it says 'Robotics' all over it - that's just the weird
implementation MS have chosen for this awsome extension.

Another option is to try the CTP of "Parallel Extensions" which is more
likely to become mainstream than the CCR (not to in any way denigrate
the CCR, of course):

http://www.microsoft.com/downloads/details.aspx?FamilyID=e848dc1d-5be3-
4941-8705-024bc7f180ba&displaylang=en