polling versus event driven...

[Daniel Bass]

hey guys.

overview
---------
I'm designing a messaging system that works on the principle of late binding
to the I/O objects, depending on the .Net class libraries present in the
local folder.

I may have an output File.DLL, and ODBC.DLL, that instantiate an abstract
parent to stream data i receive... an input .DLL allows data to be streamed
in.

The application is currently designed to be multithreaded, so that five
input channels maybe monitor at once, and data coming in can be processes
asynchronously.
the problem
------------

The problem I'm having is with the input, where I've got some DLL's, and
messages coming in...
i can either have a polling mechanism (currently instantiated), where each
monitoring thread checks for data, if none exists, then wait some amount of
time before checking again.
i've been asked to look at the other option, setting up an event delegate
system so that when a message arrives on a channel, the thread monitoring
that channel fires an event causing the data to be processed.

I don't see how this event driven mechanism would really benefit, as it
seems all thats happening is the polling (i.e., check for message, if none,
wait for a bit, try again) mechanism is no longer shared between my server
and it's I/O plugin DLL's, but rather placed entirely inside the
application.

does c# use the same thread when an event is called?
am I missing the idea behind events?
are there other alternatives / approaches to this situation?

thanks for your time.
Dan.

[Dmitriy Lapshin [C# / .NET MVP]]

Hey Daniel,

does c# use the same thread when an event is called?
Yes, the event handler will be run on the same thread the event has been
raised
are there other alternatives / approaches to this situation?
In general, it is always better to use synchronization objects such as
events or mutexes than to poll. I would suggest your plug-ins should use
synchronization objects to notify the listening thread of data available in
the channel being monitored.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

"Daniel Bass" <I'm really @ sick of spam> wrote in message
news:eO**************@TK2MSFTNGP10.phx.gbl... hey guys.

overview
---------
I'm designing a messaging system that works on the principle of late binding to the I/O objects, depending on the .Net class libraries present in the
local folder.

I may have an output File.DLL, and ODBC.DLL, that instantiate an abstract
parent to stream data i receive... an input .DLL allows data to be streamed in.

The application is currently designed to be multithreaded, so that five
input channels maybe monitor at once, and data coming in can be processes
asynchronously.
the problem
------------

The problem I'm having is with the input, where I've got some DLL's, and
messages coming in...
i can either have a polling mechanism (currently instantiated), where each
monitoring thread checks for data, if none exists, then wait some amount of time before checking again.
i've been asked to look at the other option, setting up an event delegate
system so that when a message arrives on a channel, the thread monitoring
that channel fires an event causing the data to be processed.

I don't see how this event driven mechanism would really benefit, as it
seems all thats happening is the polling (i.e., check for message, if none, wait for a bit, try again) mechanism is no longer shared between my server
and it's I/O plugin DLL's, but rather placed entirely inside the
application.

does c# use the same thread when an event is called?
am I missing the idea behind events?
are there other alternatives / approaches to this situation?

thanks for your time.
Dan.