What abstraction to use for an ASynchronous data collection driver

Question

I would like to implement a mechanism in my server application but I'm not sure which OTL abstraction would be best appropriate.

My application collects data about various types of equipements. Some of them use synchronous communication, thus generating Delphi event in my server application. (push-like) Some of them use asynchronous communication, requiring my application to periodically request the latest data available. (pull like)

Because I want my server application to stay responsive while requesting as frequently as possible the new available data, I want to put that "pull driver" within a separated thread that will request all the configured data points one by one.

I'd like my main thread to spawn this OTL object and then receive the result as a delphi event in the main thread. This would emulate the "push-like" that my server main code is already made for. Think of it as a thread you launch that periodically request a data you want to monitor and only send you an event when the value has changed.

Which OTL abstraction (high level? Low level?) do you think would be appropriate to this behavior?

Thank you.

Answer 1

I'm not sure OTL gives you much benefit here at all, to be honest. I write a lot of classes for managing hardware devices and the class model is almost invariably a plain TThread descendent. OTL is nice for spinning off tasks and work packages, queues, parallel calculations, etc. In this case, however, you don't want to do any of that. What you do want is a class that models your device and encapsulates the functions it can perform.

This is going to be a single worker thread dedicated to pumping reads and writes to the device. It is going to be a long-lived thread that will persist as long as the class that encapsulates the device remains alive - TThread makes sense for this. Your thread is going to be a simple loop that runs continuously, polling all the required data and flushing any write requests.

The class will also serve as a data cache for the device parameters and you will need some sort of synchronization devices (mutex, critical section, etc) to protect reads and writes to those fields through properties so again it makes sense that these sync objects also exist as class fields and that your thread and class model live together in a single entity. If you want event notifications, these too conveniently wrap into the same model. One device, one thread, one class. It's a perfect job for a TThread descendent.