boost asio

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

boost asio

Boost - Users mailing list

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

 


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

created_by_NS.tar.gz (4M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: boost asio

Boost - Users mailing list
> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: boost asio

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
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.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: boost asio

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
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:[hidden email]]
Sent: Tuesday, October 17, 2017 5:02 PM
To: [hidden email]
Cc: Sharma, Nishant <[hidden email]>
Subject: Re: [Boost-users] boost asio

> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: boost asio

Boost - Users mailing list
> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: boost asio

Boost - Users mailing list
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:[hidden email]]
Sent: Saturday, October 21, 2017 12:42 PM
To: Sharma, Nishant <[hidden email]>
Cc: [hidden email]
Subject: Re: [Boost-users] boost asio

> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users