How to return from synchrnous call

Question

5.00/5 (1 vote)

See more:

We are communicating with hardware through USB device.
We have implemented synchronous architecture. There is one method "Receive()" (internally used "ReadFile" method).

Now due to some reason, if hardware fails to respond then "ReadFile" API and application software get hangs.

Whole communication protocol (i.e. Write and read) has implemented in worker thread.
I don't want to change the synchrnous architecture to asynchrnous and also don't want to use another thread for "ReadFile".

Please share your valuable comments.

Posted 19-Dec-10 20:24pm

pravin29

Updated 19-Dec-10 22:25pm

Dalek Dave

v2

Add a Solution

Comments

Dalek Dave 20-Dec-10 4:25am

Edited for Readability.

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Emilio Garavaglia · Answer 1 · 2010-12-19T20:42:00

Solution 1

The software hangs until the underlying protocols timeouts expire and ReadFile finally fails.
That's what "synchronous call" means.

The problem is now "what timeouts are in the reading process"? That's not something the depend on your app, but is typically related to network protocols (TCP sokckets), hardware protocols (SCSI and the like) etc.

It is a matte of fact that certain USB drivers wait for minutes.

You can avoid these situation by letting the GUI thread to monitor the progress of the worker thread (typically with a timer) and -if it appear to be stuck for a while- abort it (and warn the user about the problem).

But -before abort- consider that the hardware timeouts have their own reason to exist. Escaping away before the hardware reports the impossibility to complete, in general makes the communication less "reliable".

A better implementation let the user aware (through the GUI) that a read is in progress and give him a way to abort the read in case it seems to him to take too long. This is less "risky" since it lets the user himself to decide.

Posted 19-Dec-10 20:42pm

Emilio Garavaglia

Comments

pravin29 20-Dec-10 3:57am

This is exactly my query "How to implement timeout for synchronous communication (Specially in case of USB communication)"?.
In case of serial communication there is DCB structure and we can set ReadTimeout. But i could not find any method for USB communication.

pravin29 20-Dec-10 4:00am

for XP i did not find any suitable method for cancel pending IO operation for synchronous communication

Dalek Dave 20-Dec-10 4:26am

Good Answer.

Emilio Garavaglia 20-Dec-10 5:15am

"... But i could not find any method for USB communication ..."
This is because you're not supposed to manage from the APP such timers.
The only thing you can do is ... kill the thread, and cleanup the partial data.

pravin29 20-Dec-10 6:14am

Thanks for your prompt reply
From my observation Even though we kill the thread, the "ReadFile" API does not terminate for synchronous communication and Killthread is not recommended to use.

Emilio Garavaglia 20-Dec-10 7:43am

Of course "kill" is not a "recommended thing" (especially if you have some action related to stack unrolling ...).
But if you design your thread accordingly, this can be done.
The ReadFile is a function called by the tread itself, so ... if the thread is dead, so it is the function (will not return since it has no place to return anymore: note that kill the thread is not the same as "delete a CThread-or-something object"!) Other driver resources will be released upon the next keepalive check.

There is no solution to your query because it's not your bug. Is an USB driver design bug, that doesn't let it timeout. (Or better: it does, after about 5 minutes)

jean Davy · Answer 2 · 2010-12-19T23:06:00

Solution 3

with WaitForMultipleObjects[^] you can wait two events or more, one is a small thread doing only "read character" and the other could be a Waitable timer, and/or a "cancel button" GUI thread.

But there is a lot of traps with such kind of code, I very strongly encourage you to use a library such as boost asio[^]

Posted 19-Dec-10 23:06pm

jean Davy

Updated 19-Dec-10 23:15pm

v2

Comments

Emilio Garavaglia 20-Dec-10 5:16am

boost asio is a C++ wrapper on the IO functionality the system gives.
It is not by itself away from the hardware timeouts.

jean Davy 20-Dec-10 6:08am

Yes Emilio, you are right, I just want to say that thread synchronisation is hard to code, too easy to introduce concurrency, memory overlap and so on, asio helps on this point, but it's needs a learning curve...

Emilio Garavaglia 20-Dec-10 7:49am

Yes, of course: but if the underlying HW doesn't timeout, and ASIO is used in synchronous way, it will stuck like everything else is synchronous will do.
If yo use it as internally asynchronous, with a synchronous call, than it does nothing more than abandon the internal reading thread.
About the learning curve ... I'm not so sure that the learning curve of boost is better than the learning curve of what is under it. Even the STL has a sometimes too wasting learning curve!
This is something I observed by looking about one-hundred developers in about 20 years! But that's a general C++ problem.

jean Davy 20-Dec-10 9:11am

Sorry Emilio, you are right, I read your question then your post too quickly, I apologize...
Learning curve, also agree, depends of motivation, more generally, it is the problem (or the interest, depends of every one) of programming languages, not only C++, sometime even more dangerous, C#, Java languages who hides "what is under" (to borrow your expression).
I stop here, too much to say, it's not the right place !