I would use a single worker thread and async / overlapped IO. IO control ports are probably overkill.
32 threads will work but it's wasteful and might make debugging more difficult. The code will probably be simpler though.
(actually with overlapped IO even the worker thread is probably unnecessary...)
[edited by - Anon Mike on May 20, 2004 1:42:38 PM]
Is 32 threads to many?
There's nothing wrong with 32 threads as long as there's not busy waiting. But if you have just a little busy waiting, you're gonna be multiplying that by 32, so make sure your thread is well designed. To me, this could be a good example of when multithreading can simplify a program.
[edited by - kdogg on May 20, 2004 9:42:57 PM]
[edited by - kdogg on May 20, 2004 9:42:57 PM]
If you are using some sort of multi I/O board with many serial ports, odds are the board buffers quite a bit of data anyway, so it''s not like you need to sit there waiting for each bit on each port.
I bet you could probably just poll and get fine results even without a single thread.
I bet you could probably just poll and get fine results even without a single thread.
Polling increases the latency of your system.
If you poll every 10ms, you''ll respond on average after 5ms. If you are trying to move lots of data over a slow line, this latency will kill you. With blocking IO or asycronous IO, you can respond within microseconds.
If you poll every 10ms, you''ll respond on average after 5ms. If you are trying to move lots of data over a slow line, this latency will kill you. With blocking IO or asycronous IO, you can respond within microseconds.
ppl answering "32 threads is nothing" clearly don''t come from the server-side world. A design using 32 threads really frightens me, both from performance and complexity reason. It''s ceraintly a strongly discouraged method on Windows. I/O completion port on the other hand is the recommended method.
As you''re using C#, async read and write is the way to go, that will benefit from i/o completion ports.
As you''re using C#, async read and write is the way to go, that will benefit from i/o completion ports.
What is the board you are programming? It''s kind of hard to say what is the best approach, you should RTFM and find out what capabilities it has and if there might be a better solution designed into it.
32 threads is kind of excessive I think, but that''s me.
Peace
32 threads is kind of excessive I think, but that''s me.
Peace
Author
First, to clear up some confusion, the hardware is custom made and was designed in the early eighties. The board doesn''t buffer anything at all.
The software I write has got to be able to sit there and wait for data to come and buffer it on it''s own. If the data does not come, I can''t sit there and wait forever. After a few attempts at getting the data, if it still fails, I need to request the data again.
For those of you that cannot believe that it takes a second to get the data off of the board.... it does. I''ve tried speeding my reads from the board up, but if i go any faster, there is no data there to be read and I just have to wait until there is. I''m using Portmon to view the data on the port and there really isn''t anything there to be read. It just doesn''t go any faster than a second (actually, about 1.276 seconds).
I''m looking into the overlapped and async i/o, but I don''t really know much about it, so I can''t say if it''s helping yet or not.
The software I write has got to be able to sit there and wait for data to come and buffer it on it''s own. If the data does not come, I can''t sit there and wait forever. After a few attempts at getting the data, if it still fails, I need to request the data again.
For those of you that cannot believe that it takes a second to get the data off of the board.... it does. I''ve tried speeding my reads from the board up, but if i go any faster, there is no data there to be read and I just have to wait until there is. I''m using Portmon to view the data on the port and there really isn''t anything there to be read. It just doesn''t go any faster than a second (actually, about 1.276 seconds).
I''m looking into the overlapped and async i/o, but I don''t really know much about it, so I can''t say if it''s helping yet or not.
Slow acccess doesn''t surprise me. Given that the h/w acts as a serial port per board
Your problem is similar to normal socket connections where the protocol wants you to send keep-alives if nothing has been transfered for X seconds.
It seems like you''re thinking that your solution must be to abort the read if a timeout occurrs. I''m not sure that''s the case.
Consider having a timestamp for "LastReceivedData" that you maintain for each port. Whenever your read-callback returns, just update that timestamp (to prevent timeout).
Then you have a separate timer (System.Threading.Timer or System.Timers.Timer) that every 5 second or so looks at all timestamps (you probably keep them in an array) to see if there are timeouts. For all ports where there have been a timeout, simply issue the request again. Your pending read does not need to return until there actually is data to read. If there have been timeouts in between causing new requests isn''t really interesting for your read-callback.
Another thing. How do you open the port? Don''t remember if you actually can use serial ports directly in 1.1 framework, or if you call CreateFile yourself. In any case, you could (as an alternative to the timestamps I suggested above) set a read-timeout on the serial port, and then your callback would return with 0 bytes to read. If that happens you know it''s because of a timeout, and you can issue the request again.
Your problem is similar to normal socket connections where the protocol wants you to send keep-alives if nothing has been transfered for X seconds.
It seems like you''re thinking that your solution must be to abort the read if a timeout occurrs. I''m not sure that''s the case.
Consider having a timestamp for "LastReceivedData" that you maintain for each port. Whenever your read-callback returns, just update that timestamp (to prevent timeout).
Then you have a separate timer (System.Threading.Timer or System.Timers.Timer) that every 5 second or so looks at all timestamps (you probably keep them in an array) to see if there are timeouts. For all ports where there have been a timeout, simply issue the request again. Your pending read does not need to return until there actually is data to read. If there have been timeouts in between causing new requests isn''t really interesting for your read-callback.
Another thing. How do you open the port? Don''t remember if you actually can use serial ports directly in 1.1 framework, or if you call CreateFile yourself. In any case, you could (as an alternative to the timestamps I suggested above) set a read-timeout on the serial port, and then your callback would return with 0 bytes to read. If that happens you know it''s because of a timeout, and you can issue the request again.
quote:Original post by Anonymous Poster
Given that the h/w acts as a serial port per board...
(forgot to complete the sentence)
...it seems like PeterTarkus'' suggestion (rtfm) won''t help you. I think you''re on the right track. Now you need to decide whether to design using the traditional *nix-way, with one thread per request, or the Windows-way using async I/O and I/O completion ports.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
