Threads or Timers

Hey gang,

I’d like people’s opinion on if I should use threads or timers in a particular use case. I’ve used both and am struggling with knowing which is better.

When my app starts up, it makes telnet connections to multiple devices on a network. The number of devices may vary but for round numbers, let’s say it’s 100 devices. Yes, it could really be that large. For each device, I log in, and grab some initial information about the device. This whole process for each device takes a very short period of time - it’s not long nor is it a lot of processing going on.

I had been using a thread pool manager and running about 15 threads at a time.

Then I switched to using a timer based solution where I am queuing up multiple timers to fire and do the work.

Both seem to work equally well except I’m wondering if on larger systems (like the 100 number example), if using threads would be faster and more efficient than 100 timers. For small systems like I play with of maybe 12 devices, either way is equally quick and good. Larger ones like customers have I can’t really know as I’m not in front of it to witness. So just looking for what people think is best.

Thanks.

Jon

why not have a pool of threads (say 15 like you mentioned)
create a queue of devices to be queried.

fire up the first 15
as each thread completes its mission, have it check the queue to see if there are more devices to check, and if so take the next one and start with it,
continue until the queue is empty.
this way you will query 15 devices at a time, with each device allowd to be as fast or as slow as required

[quote=213763:@Dave S]why not have a pool of threads (say 15 like you mentioned)
create a queue of devices to be queried.

fire up the first 15
as each thread completes its mission, have it check the queue to see if there are more devices to check, and if so take the next one and start with it,
continue until the queue is empty.
this way you will query 15 devices at a time, with each device allowd to be as fast or as slow as required[/quote]

That’s what I had been doing. But since I’m doing socket IO and since my routines run fairly fast, I wasn’t sure threads was the right way.

Or do you mean create a queue of timers?

That would argue for “none of the above”. The sockets run async and their DataAvailable events run in the main thread, regardless of where the communication was initiated, so a thread is pretty much pointless. Since the communication happens quickly, I’m not sure a timer does more than add overhead.

Exactly how does a timer/thread help in this situtation? Perhaps I am missing something obvious.

[quote=213777:@Tim Hare]That would argue for “none of the above”. The sockets run async and their DataAvailable events run in the main thread, regardless of where the communication was initiated, so a thread is pretty much pointless. Since the communication happens quickly, I’m not sure a timer does more than add overhead.

Exactly how does a timer/thread help in this situtation? Perhaps I am missing something obvious.[/quote]

Because running in a loop of X number of devices does bog down and slow up the UI. Maybe I’m not being quite asynchronous enough (I’m slowly getting to the point of being asynchronous after being completely synchronous initially)… You have a point…

If there is a chance that one of the devices will be down or the network down, then I would use a thread. This lets the UI continue and the user can do something else while it is waiting to connect or be rejected.

If I understand the case well, the GUI will just continue being responsive after initiating the communication to all sockets. You could use just one timer to check which events did not come within it’s period and start another trial for just these sockets to connect. for let’s say max 5 times before reporting.