unknown
1970-01-01 00:00:00 UTC
The documentation needs to state this clearly in some manner in both the
tutorial and reference sections.
Perhaps I need to put my hand up!
ago.
The best solution I see is to add additional API to create exclusive
strands.
asio::io_service::strand(bool exclusive = false) {...}
This would be nice. However to make things even more explicit perhaps a
different type (
asio::io_service::strand_exclusive) may be a better option.
Regards,
--
Greg
--f46d0438907dbba9b904e987c09a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:arial">Hi All,</span></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:arial"><br> </span></div><div class="gmail_default">Thanks for your responses. I wish I had of posted here�earlier�rather than the boost lists.</div><div class="gmail_default"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"> <span style="font-family:arial">On 24 October 2013 16:54, Marat Abrarov </span><span dir="ltr" style="font-family:arial"><<a href="mailto:***@mail.ru" target="_blank">***@mail.ru</a>></span><span style="font-family:arial"> wrote:</span><br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> It may be a change of behaviour and a problem for you, but strictly<br>
> speaking I don't think it is a bug. The strand concept guarantees that<br>
> handlers wrapped on the _same_ strand will _not_ execute concurrently. It<br>
> does not guarantee that handlers wrapped on _different_ strands _will_ be<br>
> allowed to execute concurrently.<br>
<br>
</div>I think this has to be noted in documentation to prevent misunderstanding.</blockquote><div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
Yes I agree with this. When I realised what was happening I looked at the documentation very closely to for any hints as to whether the behavior was expected. The documentation doesn't fully explain the current operation:</div>
</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">"<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:15px">An boost::asio::strand guarantees that, for those handlers that are dispatched through it, an executing handler will be allowed to complete before the next one is started. This is guaranteed irrespective of the number of threads that are calling </span><a class="" href="http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/io_service/run.html" title="io_service::run" style="font-size:13px;text-decoration:none;color:rgb(156,90,156);font-family:sans-serif;line-height:15px">io_service::run()</a><span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:15px">. Of course, the handlers may still execute concurrently with other handlers that were not dispatched through an boost::asio::strand, or were dispatched through a different boost::asio::strand object."</span></div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:15px"><br></span></div><div class="gmail_default"><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0);line-height:15px">The following snippet is true: "</span><span style="font-family:sans-serif;color:rgb(0,0,0);font-size:13px;line-height:15px">Of course, the handlers may still execute concurrently </span><span style="font-family:sans-serif;color:rgb(0,0,0);font-size:13px;line-height:15px">with other handlers that were</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0);line-height:15px">... ...</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0);line-height:15px"> dispatched through a different boost::asio::strand object</span><font color="#000000" face="sans-serif"><span style="line-height:15px">". What it doesn't say is that handlers may execute sequentially with handlers dispatched through a different boost::asio::strand object. There are no guarantees.</span></font></div>
<div class="gmail_default"><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:15px"><br></span></div><div class="gmail_default"><font color="#000000" face="sans-serif"><span style="line-height:15px">I understand that this is the desired behaviour (and why). From a users point of view I think it is unnatural. If the user creates a strand object they will naturally think that they operate independently as they should not be concerned with the implementation of the object.</span></font></div>
<div class="gmail_default"><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:15px"><br></span></div><div class="gmail_default">The documentation needs to state this clearly in some manner in both the tutorial and reference sections.</div>
<div class="gmail_default"><br></div><div class="gmail_default">Perhaps I need to put my hand up!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> I would guess the reason it is done like this is because the alternative<br>
> does not scale well; if every strand has its own implementation then you<br>
> are continually creating and destroying mutexes and might also hit OS<br>
> constraints on the number of mutexes if the number of strands is large.<br>
<br>
</div>Yes. This is the only reason. It was discussed (this mail list) some years<br>
ago.<br>
<br>
The best solution I see is to add additional API to create exclusive<br>
strands.<br>
Something like optional parameter at constructor of strand:<br>
<br>
<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"></div>asio::io_service::strand(bool exclusive = false) {...}<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">
This would be nice. However to make things even more explicit perhaps a different type (<div class="gmail_default" style="display:inline"></div><span style="font-family:arial">asio::io_service::strand_exclusive</span>) may be a better option.</div>
</div><div><br></div></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Regards,</div><br></div>-- <br><div dir="ltr"><div>Greg</div></div>
</div></div>
--f46d0438907dbba9b904e987c09a--
tutorial and reference sections.
Perhaps I need to put my hand up!
I would guess the reason it is done like this is because the alternative
does not scale well; if every strand has its own implementation then you
are continually creating and destroying mutexes and might also hit OS
constraints on the number of mutexes if the number of strands is large.
Yes. This is the only reason. It was discussed (this mail list) some yearsdoes not scale well; if every strand has its own implementation then you
are continually creating and destroying mutexes and might also hit OS
constraints on the number of mutexes if the number of strands is large.
ago.
The best solution I see is to add additional API to create exclusive
strands.
asio::io_service::strand(bool exclusive = false) {...}
different type (
asio::io_service::strand_exclusive) may be a better option.
Regards,
--
Greg
--f46d0438907dbba9b904e987c09a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:arial">Hi All,</span></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:arial"><br> </span></div><div class="gmail_default">Thanks for your responses. I wish I had of posted here�earlier�rather than the boost lists.</div><div class="gmail_default"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"> <span style="font-family:arial">On 24 October 2013 16:54, Marat Abrarov </span><span dir="ltr" style="font-family:arial"><<a href="mailto:***@mail.ru" target="_blank">***@mail.ru</a>></span><span style="font-family:arial"> wrote:</span><br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> It may be a change of behaviour and a problem for you, but strictly<br>
> speaking I don't think it is a bug. The strand concept guarantees that<br>
> handlers wrapped on the _same_ strand will _not_ execute concurrently. It<br>
> does not guarantee that handlers wrapped on _different_ strands _will_ be<br>
> allowed to execute concurrently.<br>
<br>
</div>I think this has to be noted in documentation to prevent misunderstanding.</blockquote><div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
Yes I agree with this. When I realised what was happening I looked at the documentation very closely to for any hints as to whether the behavior was expected. The documentation doesn't fully explain the current operation:</div>
</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">"<span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:15px">An boost::asio::strand guarantees that, for those handlers that are dispatched through it, an executing handler will be allowed to complete before the next one is started. This is guaranteed irrespective of the number of threads that are calling </span><a class="" href="http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/io_service/run.html" title="io_service::run" style="font-size:13px;text-decoration:none;color:rgb(156,90,156);font-family:sans-serif;line-height:15px">io_service::run()</a><span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:15px">. Of course, the handlers may still execute concurrently with other handlers that were not dispatched through an boost::asio::strand, or were dispatched through a different boost::asio::strand object."</span></div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-size:13px;color:rgb(0,0,0);font-family:sans-serif;line-height:15px"><br></span></div><div class="gmail_default"><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0);line-height:15px">The following snippet is true: "</span><span style="font-family:sans-serif;color:rgb(0,0,0);font-size:13px;line-height:15px">Of course, the handlers may still execute concurrently </span><span style="font-family:sans-serif;color:rgb(0,0,0);font-size:13px;line-height:15px">with other handlers that were</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0);line-height:15px">... ...</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0);line-height:15px"> dispatched through a different boost::asio::strand object</span><font color="#000000" face="sans-serif"><span style="line-height:15px">". What it doesn't say is that handlers may execute sequentially with handlers dispatched through a different boost::asio::strand object. There are no guarantees.</span></font></div>
<div class="gmail_default"><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:15px"><br></span></div><div class="gmail_default"><font color="#000000" face="sans-serif"><span style="line-height:15px">I understand that this is the desired behaviour (and why). From a users point of view I think it is unnatural. If the user creates a strand object they will naturally think that they operate independently as they should not be concerned with the implementation of the object.</span></font></div>
<div class="gmail_default"><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:15px"><br></span></div><div class="gmail_default">The documentation needs to state this clearly in some manner in both the tutorial and reference sections.</div>
<div class="gmail_default"><br></div><div class="gmail_default">Perhaps I need to put my hand up!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> I would guess the reason it is done like this is because the alternative<br>
> does not scale well; if every strand has its own implementation then you<br>
> are continually creating and destroying mutexes and might also hit OS<br>
> constraints on the number of mutexes if the number of strands is large.<br>
<br>
</div>Yes. This is the only reason. It was discussed (this mail list) some years<br>
ago.<br>
<br>
The best solution I see is to add additional API to create exclusive<br>
strands.<br>
Something like optional parameter at constructor of strand:<br>
<br>
<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"></div>asio::io_service::strand(bool exclusive = false) {...}<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">
This would be nice. However to make things even more explicit perhaps a different type (<div class="gmail_default" style="display:inline"></div><span style="font-family:arial">asio::io_service::strand_exclusive</span>) may be a better option.</div>
</div><div><br></div></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Regards,</div><br></div>-- <br><div dir="ltr"><div>Greg</div></div>
</div></div>
--f46d0438907dbba9b904e987c09a--