Is 32 threads to many?
Author
If you''ve read any of my other questoins, you may know that i''m working with a custom piece of software that utalizes the serial port. The hardware is very slow.
If I leave the serial comm code on the same thread as the GUI, then there are large parts of time where the GUI is useless because the code is pulling data off of the board. To fix this porblem, I simply create a worker thread to handle reading data off of the board.
Now, to further the troubles, I''m supose to pull the data off of the board every 30 seconds. This isn''t a problem for a few boards; however, the could be up to 32 boards connected to a single computer and at times, it can take up to a second to pole a board for it''s data. Clearly 32 boards X 1 second of time for data access is greater then the 30 second window I have to pull data.
Pulling the data is not CPU instensive, it''s just slow and a lot of waiting on hardware. Would it be alright to spawn a thread for each board and have a possiblity of up to 32 threads? Or should I use more like a thread pool with, say, eight boards per thread?
Just looking for opinions. The software runs on windows xp and is written in C# (.Net). thanks for any feedback
You might be able to simply use overlapped I/O. If you''re accessing the serial port using CreateFile, ReadFile, etc., then you can create the file as overlapped (one of the flags somewhere), and then it will run in the background; Windows handles the "threading" on its own. I don''t really think it actually spawns an entire thread for each overlapped read call, but it works about the same. Then you would just call WaitForMultipleObjects, using an array with all of your hEvent handles (from the OVERLAPPED structure). Whenever any of the ports had any activity, your Wait call would return, and you could find out which one(s) is active, handle whatever you need to handle, and then wait again until more activity occurs.
However, if you just stick with your current model, considering this stuff occurs within a timeframe of seconds, not milliseconds or microseconds, I can pretty much guarantee you that 32 threads is going to have no significant impact on performance, unless you thoroughly screw up your management of them somewhere.
However, if you just stick with your current model, considering this stuff occurs within a timeframe of seconds, not milliseconds or microseconds, I can pretty much guarantee you that 32 threads is going to have no significant impact on performance, unless you thoroughly screw up your management of them somewhere.
quote:Original post by Mike
If you''ve read any of my other questoins, you may know that i''m working with a custom piece of software that utalizes the serial port. The hardware is very slow.
If I leave the serial comm code on the same thread as the GUI, then there are large parts of time where the GUI is useless because the code is pulling data off of the board. To fix this porblem, I simply create a worker thread to handle reading data off of the board.
Now, to further the troubles, I''m supose to pull the data off of the board every 30 seconds. This isn''t a problem for a few boards; however, the could be up to 32 boards connected to a single computer and at times, it can take up to a second to pole a board for it''s data. Clearly 32 boards X 1 second of time for data access is greater then the 30 second window I have to pull data.
Pulling the data is not CPU instensive, it''s just slow and a lot of waiting on hardware. Would it be alright to spawn a thread for each board and have a possiblity of up to 32 threads? Or should I use more like a thread pool with, say, eight boards per thread?
Just looking for opinions. The software runs on windows xp and is written in C# (.Net). thanks for any feedback
Since you''re writing this on winxp/c# I assume "every 30 seconds" isn''t a hard RT requirement. Where is your bottleneck? Transferring data over serial(in which case you might consider a faster interface than rs-232) or is that 1 second spent mostly waiting for the board to collect data w/ little traffic over serial?
How are you going to place 32 comports in the PC?
If you use blocking IO, one thread per com port is the way to go.
You could also use asyncronous IO (overlapped IO or completion ports) which would only require one thread.
If you use blocking IO, one thread per com port is the way to go.
You could also use asyncronous IO (overlapped IO or completion ports) which would only require one thread.
quote:Original post by Magmai Kai Holmlor
How are you going to place 32 comports in the PC?
It''s possible, I''ve crammed many com ports onto pc hardware before. But never with windows though, that''ll be interesting. You just get 4 PCI cards with 8 serial ports/card. And you have to get cards that support IRQ sharing, because otherwise you''re screwed.
There are plenty of devices that allow lots of comm ports. I''ve used one that was an external box with 8 ports on it that you could chain together to get 256 ports running off 1 card.
I don''t see how it would take 1 second to pull data off of each port, assuming there''s buffering on the card. While you''re reading from one card, the buffer will fill on the other cards, so reading from those cards will be fast once you get to them.
If the card is truly ancient, and only has lik 8 bytes of buffering, then you need to read in non-blocking mode, meaning you don''t read more data than what''s there; do your own buffering, and round-robin between the cards. Once there is enough data in the buffer for one of the cards, do what you need to do with it, clear the buffer, and continue.
Overlapped I/O is one way of getting non-blocking I/O on Windows.
If the card is truly ancient, and only has lik 8 bytes of buffering, then you need to read in non-blocking mode, meaning you don''t read more data than what''s there; do your own buffering, and round-robin between the cards. Once there is enough data in the buffer for one of the cards, do what you need to do with it, clear the buffer, and continue.
Overlapped I/O is one way of getting non-blocking I/O on Windows.
Check out IOCP. IOCP can literally manage thousands of OVERLAPPED I/O handles per processors. Now if you had multiple processors, you can process double the count.
32 threads count is no problem.
Kuphryn
32 threads count is no problem.
Kuphryn
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
