Hi, I have created an Asynchronous TCP server and client and it works fine. Since it is asynchronous, it uses API's like async_read, async_write etc.. Is it possible that the same code be used to do "synchronous" communication which results in blocking any further task in the queue unless the current i/o task is complete ? I have attached the example hereby. It has two folder for server and client.. First the server needs to be run and then the client. Best Regards, Nishant Sharma
I have created an Asynchronous TCP server and client and it works fine. Since it is asynchronous, it uses API’s like async_read, async_write etc.. Is it possible that the same code be used to do “synchronous” communication which results in blocking any further task in the queue unless the current i/o task is complete ?
You can do that with synchronization: std::condition_variable cond; std::mutex mutex; auto done=false; after you call asyn_write/read, you wait until done==true and in your call back function, you acquire the mutex, done == true, then notify_all(). F
Hi Frédéric,
I got it.. Just one more point..
You mentioned:
after you call asyn_write/read, you wait until done==true and in your call back function, you acquire the mutex, done == true, then notify_all().
a)
Should this wait be not done before we call sync read/write?
OR
Is it that we do it after calling async read/write so that threads can do their I/O work and the actual callback functions are called sequentially?
b)
Should we use interprocess_mutex and interprocess_condition instead or normal mutex and condition since different clients and the server will run in different processes ?
Best Regards,
Nishant Sharma
Best Regards,
Nishant Sharma
-----Original Message-----
From: Frédéric [mailto:ufospoke@gmail.com]
Sent: Tuesday, October 17, 2017 5:02 PM
To: boost-users@lists.boost.org
Cc: Sharma, Nishant
I have created an Asynchronous TCP server and client and it works fine. Since it is asynchronous, it uses API’s like async_read, async_write etc.. Is it possible that the same code be used to do “synchronous” communication which results in blocking any further task in the queue unless the current i/o task is complete ?
You can do that with synchronization: std::condition_variable cond; std::mutex mutex; auto done=false; after you call asyn_write/read, you wait until done==true and in your call back function, you acquire the mutex, done == true, then notify_all(). F
I got it.. Just one more point.. You mentioned: after you call asyn_write/read, you wait until done==true and in your call back function, you acquire the mutex, done == true, then notify_all().
Should this wait be not done before we call sync read/write? OR Is it that we do it after calling async read/write so that threads can do their I/O work and the actual callback functions are called sequentially?
wait right after otherwise, you will never call async_(read|write).
Should we use interprocess_mutex and interprocess_condition instead or normal mutex and condition since different clients and the server will run in different processes ?
std::mutex and std::condition_variable are just fine. F
Hi Frederic,
I did not understand your comment...
My point was that I do a cond wait before I call async(read|write)
From within the callback function, I do a notify so that the next async command can be executed.
Will this not result in same functionality as you mentioned where wait is done after calling async(read|write) ?
Best Regards,
Nishant Sharma
-----Original Message-----
From: Frédéric [mailto:ufospoke@gmail.com]
Sent: Saturday, October 21, 2017 12:42 PM
To: Sharma, Nishant
I got it.. Just one more point.. You mentioned: after you call asyn_write/read, you wait until done==true and in your call back function, you acquire the mutex, done == true, then notify_all().
Should this wait be not done before we call sync read/write? OR Is it that we do it after calling async read/write so that threads can do their I/O work and the actual callback functions are called sequentially?
wait right after otherwise, you will never call async_(read|write).
Should we use interprocess_mutex and interprocess_condition instead or normal mutex and condition since different clients and the server will run in different processes ?
std::mutex and std::condition_variable are just fine. F
On 17/10/2017 16:48, Sharma, Nishant wrote:
I have created an Asynchronous TCP server and client and it works fine.
Since it is asynchronous, it uses API’s like async_read, async_write etc..
Is it possible that the same code be used to do “synchronous” communication which results in blocking any further task in the queue unless the current i/o task is complete ?
That kinda defeats the point of using asynchronous functions to begin with. Blocking functions are the arch-nemesis of asynchronous code. With asynchronous code, if you don't want to do something until the task is complete, then don't start it until the completion callback is called, and only have one operation "in flight" at any given moment. If you want to have operations executing in parallel but merely want to make sure that the handlers don't get called concurrently, then link them to the same strand. (This is not necessary but not harmful when only one thread is running the io_service.) If you want to make sure that nothing happens in parallel and everything blocks until it's done, then use synchronous calls instead. There's an example for that too. Bear in mind that while this is simpler to code, it's also less scalable.
participants (3)
-
Frédéric -
Gavin Lambert -
Sharma, Nishant