[prev in list] [next in list] [prev in thread] [next in thread]
List: boost-users
Subject: Re: [Boost-users] [multi state machine/ MSM] execute_queued_events
From: christophe.j.henry () gmail ! com
Date: 2014-09-25 5:52:24
Message-ID: 1084FE2C792346AE9990E5F799E9843B () pcasync
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> I modeled the states of a simple network communication (implemented using \
> boost::asio) using boost::msm. The states are: Disconnected -> Connecting -> Idle \
> -> Sending Message -> Waiting for Response -> Idle
> I have multiple threads, which use this network communication to send messages.
> While the state "Waiting for Response" is active, I cannot send any further \
> message. So when a thread wants to send a message, I enqueue this in a separate \
> queue and I read this queue only when entering state "Idle". The reason for the \
> separate queue is that the transition "Waiting for Response -> Idle" can only be \
> triggered through the boost::asio read handler.
> Maybe this can be done easier with your new implementation?
It will but not yet because the queue handling is missing in the lockfree part. I \
need some time to finish this.
Seeing the use case I think you might be using the wrong tool. What you want is not \
to enqueue your events in advance, what you want is to defer the event with the \
message until you enter Idle. You might want to have a look at deferred events. Then \
for the synchronization you can just lock any calls to process_event as one of them \
will eventually process the deferred event too. When I'm done with lockfree, you \
will simply have to remove the lock and it will work the same, just faster.
I personally have often the same to implement and I use from my upcoming \
boost.asynchronous library a single_thread_scheduler to serialize calls.
[Attachment #5 (text/html)]
<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: \
normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'></DIV> <DIV dir=ltr>
<DIV>>I modeled the states of a simple network communication (implemented
using boost::asio) using boost::msm. </DIV>
<DIV>>The states are: <B>Disconnected -> Connecting -> Idle ->
Sending Message -> Waiting for Response -> Idle</B></DIV>
<DIV>></DIV>
<DIV>>I have multiple threads, which use this network communication to send
messages. </DIV>
<DIV>>While the state "Waiting for Response" is active, I cannot send any
further message. </DIV>
<DIV>>So when a thread wants to send a message, I enqueue this in a separate
queue and I read this queue only when entering state "Idle". </DIV>
<DIV>>The reason for the separate queue is that the transition "Waiting for
Response -> Idle" can only be triggered through the boost::asio read
handler.</DIV>
<DIV>></DIV>
<DIV>>Maybe this can be done easier with your new implementation?</DIV>
<DIV> </DIV>
<DIV>It will but not yet because the queue handling is missing in the lockfree
part. I need some time to finish this.</DIV>
<DIV> </DIV>
<DIV>Seeing the use case I think you might be using the wrong tool. What you
want is not to enqueue your events in advance, what you want is to defer the
event with the message until you enter Idle. You might want to have a look at
deferred events.</DIV>
<DIV>Then for the synchronization you can just lock any calls to process_event
as one of them will eventually process the deferred event too. </DIV>
<DIV>When I'm done with lockfree, you will simply have to remove the lock and it
will work the same, just faster.</DIV>
<DIV> </DIV>
<DIV>I personally have often the same to implement and I use from my upcoming
boost.asynchronous library a single_thread_scheduler to serialize
calls.</DIV></DIV></DIV></DIV></DIV></BODY></HTML>
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic