Home/ Questions/Q 8390473
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T18:59:47+00:00

I’ve developed some code that receives a series of values from a hardware device,

  • 0

I’ve developed some code that receives a series of values from a hardware device, every 50ms in the form of name/value pairs. I want to develop a pub/sub service whereby subscribers can be notified when the value of a particular item changes. The Subscribe method might look something like this:-

public void Subscribe(string itemName, Action<string, long> callback)

The code that reads the hardware values will check if a value has changed since last time. If so, it will iterate through any subscribers for that item, calling their delegates. As it stands, the delegates will be called on the same thread which isn’t ideal – I need to keep the polling as fast as possible. What’s the best approach for calling the callback delegates on separate threads? Should the subscribers pass in (say) a task/thread, or should the publisher be responsible for spinning these up?

Note that I need to pass a couple of parameters to the delegate (the item name and its value), so this might affect the approach taken. I know you can pass a single “state” object to tasks but it feels a bit unintuitive requiring the subscribers to implement an Action callback delegate (which must then be cast to some other type containing the name and value).

Also, I’m assuming that creating a new task/thread each time a delegate is called will hurt performance, so some kind of “pool” might be required?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would maintain the same structure that you now have and put the responsibility of prompt action onto the callbacks, ie. the callbacks should not block or perform complex, lengthy actions directly.

    If a particular callback needs to perform any lengthy action, it should queue off the Action data to a thread of its own and then return ‘immediately’, eg. it might BeginInvoke/PostMessage the data to a GUI thread, queue it to a thread that inserts into DB table or queue it to a logger, (or indeed, any combo chained together). These lengthy/blocking actions can then proceed in parallel while the device interface continues to poll.

    This way, you keep the working structure you have and do not have to inflict any inter-thread comms onto callbacks that do not need it. The device interface remains encapsulated, just firing callbacks.

    EDIT:

    ‘creating a new task/thread each time a delegate is called will hurt performance’ – yes, and also it would be difficult to maintain state. Often, such threads are written as while(true) loops with some signaling call at the top, eg. a blocking queue pop(), and so only need creating once, at startup, and never need terminating.

    • 0