Hello,
Long time VB .NET person here. I'm about to make my first foray into something a bit real-time and interactive (it's only a model / simulation, I'm not going to hurt anyone!).....
I have a bit of a grey area in my knowledge about threads vs processes, etc. I have previously created worker threads to do long-running jobs and so on. For this new development, I have a USB connected device which provides digital inputs and outputs which are read and set by calls to a DLL.
I have the basics working, and have two specific requirements:
I'm inclined to approach the first by kicking off a separate thread which will continuously read the inputs and raise an event whenever anything changes. That would allow the reading to go on with little/no impact on what I am doing elsewhere in the code and gets things translated to an event-driven model as early in the process as possible. Is a separate thread the right way to go, or am I missing something?
The second, feels like it should be a "queue" written to by the rest of my code and then read by a separate thread (process?) which is responsible for passing the data out through the interface. This is even less clear to me than the first point!
So, no specific question, but I'm hopeful that someone can give me some "best practice" guidance/pointers on how best to handle these asynchronous tasks.
Thanks.
Long time VB .NET person here. I'm about to make my first foray into something a bit real-time and interactive (it's only a model / simulation, I'm not going to hurt anyone!).....
I have a bit of a grey area in my knowledge about threads vs processes, etc. I have previously created worker threads to do long-running jobs and so on. For this new development, I have a USB connected device which provides digital inputs and outputs which are read and set by calls to a DLL.
I have the basics working, and have two specific requirements:
- Continuous polling of the inputs to see whether anything has changed.
- Asynchronous writing to the outputs.
I'm inclined to approach the first by kicking off a separate thread which will continuously read the inputs and raise an event whenever anything changes. That would allow the reading to go on with little/no impact on what I am doing elsewhere in the code and gets things translated to an event-driven model as early in the process as possible. Is a separate thread the right way to go, or am I missing something?
The second, feels like it should be a "queue" written to by the rest of my code and then read by a separate thread (process?) which is responsible for passing the data out through the interface. This is even less clear to me than the first point!
So, no specific question, but I'm hopeful that someone can give me some "best practice" guidance/pointers on how best to handle these asynchronous tasks.
Thanks.
