ThreadPool.RegisterWaitForSingleObject()

[Markus Ewald]

Hi!

I'm writing a component that is responsible for simultaneous communications
with multiple hardware devices, connected either serially (RS232) or as per
means of TCP/IP over a LAN connection. Active connections are represented by
instances of a 'Connection' class which derives from System.IO.Stream.
Oversimplified, each Connection is owned by a communications driver which
handles incoming and outgoing packets. Oversimplified, as I said.

(for the UML-savvy guys)

+------------------+
| System.IO.Stream |
|------------------|
| +read() |
| +write() |
+------------------+

 

[Lloyd Dupont]

interesting question!
well I quickly glance at all subclass of WaitHandle and none of them has any
event.

But I have an idea of possible solution for you.

- each connection should have its own wait handle
- there should be a "device manager" class which knows all devices and their
states (busy/ready)1

anytime a connection want some data from a device it ask the device manager
which, either:
- 'register the connection as pending on such device' and call the
(internal) .Wait() method of the connection
- or return the device data if it's ready.

whenever a device is ready it notify the device manager which, then, wake up
any appropriate pending connection.

simple, hey?!

 

[Markus Ewald]

interesting question!
well I quickly glance at all subclass of WaitHandle and none of them has
any event.

But I have an idea of possible solution for you.

- each connection should have its own wait handle
- there should be a "device manager" class which knows all devices and
their states (busy/ready)1

anytime a connection want some data from a device it ask the device
manager which, either:
- 'register the connection as pending on such device' and call the
(internal) .Wait() method of the connection
- or return the device data if it's ready.

whenever a device is ready it notify the device manager which, then, wake
up any appropriate pending connection.

simple, hey?!

Just for clarity, in my terminology, the 'Connection' is what transmits and
receives data and a 'Device' would be a programmatical representation of the
methods and attributes of an actual hardware device.

Your idea might work, I my object model really was that simple. However,
what I labelled 'CommunicationsDriver' is really a chain of filters for
interpreting various nested intermediate protocols (eg. telnet, proprietary
packetizing protocols and so on) on top of which is a specialized device
driver which represents the properties and possible commands of the actual
hardware device as an object tree.

Now, because these filter layers might transmit data over the connection to
each other (like the telnet handshaking stuff) without the top layer even
grasping a byte of it, there is no place such a device manager entity could
be placed at.

My 'EventMonitor' idea already solves the problem, but I hoped there would
be something in the .NET framework sparing me from writing this thing. Like
the System.Threading.Timer class which magically provides timed asynchronous
callbacks without using a second thread. Well, I'll think about your
suggestion, maybe I can do something with it

-Markus-