Boost Meta State Machine Infinite Loop Seg Fault - c++11

I am attempting to use Boost State Machine, but I have encountered a Segmentation Fault when running my machine in an infinite loop. Essentially I have the same example in the boost state machine functor example shown below:
The only difference is that I now trigger "event1" to occur as soon as I enter State4, hence creating a loop. This works for several thousand iterations but then it will seg fault. Am I breaking some kind of UML rule and overflowing the stack? I basically only have one blocking event and then I want all the other states to trigger automatically, and then end up in State4 (which in reality would be a blocking call waiting for a message from the network for example). How would I properly implement this using Meta State Machine so I don't blow up the stack?
UPDATE
I've included a the source code that is causing my problems here:
http://pastebin.com/fu6rzF0Q
This is basically the example in functor front end except with the following changes:
Added "pretend" blocking call function:
struct BlockingCall {
template <class EVT, class FSM, class SourceState, class TargetState>
void operator()(EVT const &, FSM &, SourceState &, TargetState &) {
std::cout << "my_machine::Waiting for a thing to happen..." << std::endl;
// Pretend I'm actually waiting for something
std::this_thread::sleep_for(std::chrono::milliseconds(100));
std::cout << "my_machine::OMG the the thing happened!" << std::endl;
}
};
And I also updated the last line in the transition table:
struct transition_table : mpl::vector<
// Start Event Next Action Guard
// +---------+-------------+---------+---------------------+----------------------+
Row < State1 , none , State2 >,
Row < State2 , none , State3 , State2ToState3 >,
Row < State3 , none , State4 , none , always_false >,
// +---------+-------------+---------+---------------------+----------------------+
Row < State3 , none , State4 , State3ToState4 , always_true >,
Row < State4 , none , State1 , BlockingCall >
// +---------+-------------+---------+---------------------+----------------------+
> {};
Notice that there is no longer an event that needs to triggered to move from State4 to State1. This code with out a doubt give you a seg fault and will have a stack trace that is 1000s of lines long.
I should also note that regardless of the time I wait, I always eventually seg fault. I've played around with changing the sleep to 1 - 100 and it will eventually die. I guess I need some way of unrolling the stack once a single loop has completed.
UPDATE 2
So I found that I don't seg fault when I trigger on the event in an infinite loop. Here is what I did:
First I set the transition table back to the original example:
struct transition_table : mpl::vector<
// Start Event Next Action Guard
// +---------+-------------+---------+---------------------+----------------------+
Row < State1 , none , State2 >,
Row < State2 , none , State3 , State2ToState3 >,
Row < State3 , none , State4 , none , always_false >,
// +---------+-------------+---------+---------------------+----------------------+
Row < State3 , none , State4 , State3ToState4 , always_true >,
Row < State4 , event1 , State1 , none >
// +---------+-------------+---------+---------------------+----------------------+
> {};
Then I changed the main program to the following:
void test() {
my_machine p;
// needed to start the highest-level SM. This will call on_entry and mark the
// start of the SM
// in this case it will also immediately trigger all anonymous transitions
p.start();
// this event will bring us back to the initial state and thus, a new "loop"
// will be started
while (true) {
p.process_event(event1());
}
}
And now I have been running at full speed (no sleeps) and I haven't seg faulted. Based on this, it seems there is no way to start a state machine and just have it run and process internal events, is that correct? I always have to have some process on the outside that triggers at least on even?
UPDATE 3
Ultimately my goal is to implement something like the following picture:
My intent is to have the state machine started, and then it will simply wait for incoming messages without any further intervention.

I have come to the conclusion that there is simply no way to have the state machine have an internal loop if you call fsm.process_event(e1) inside any of the actions/guards/entry/exit statements. I believe that the problem is that every time you make that call, you push more information on the stack until eventually you overflow the stack. This is also true if you have anonymous transitions create an infinite loop in the state machine. So my conclusion is that you must have at least ONE external event to trigger the loop. Hence the following code is the best solution I have found so far:
void test() {
my_machine p;
p.start();
// Must have at least 1 triggering external event to not overflow the stack
while (true) {
p.process_event(event1());
}
}

Related

Time of day clock.

Question: Suppose that you have a clock chip operating at 100 kHz, that is, every ten microseconds the clock will tick and subtract one from a counter. When the counter reaches zero, an interrupt occurs. Suppose that the counter is 16 bits, and you can load it with any value from 0 to 65535. How would you implement a time of day clock with a resolution of one second.
My understanding:
You can't store 100,000 in a 16 bit counter, but you can store 50,000 so could you would you have to use some sort of flag and only execute interrupt every other time?
But, i'm not sure how to go about implement that. Any form of Pseudocode or a general explanation would be most appreciated.
Since you can't get the range you want in hardware, you would need to extend the hardware counter with some sort of software counter (e.g. everytime the hardware counter goes up, increment the software counter). In your case you just need an integer value to keep track of whether or not you have seen a hardware tick. If you wanted to use this for some sort of scheduling policy, you could do something like this:
static int counter; /* initilized to 0 somewhere */
void trap_handler(int trap_num)
{
switch(trap_num)
{
...
case TP_TIMER:
if(counter == 0)
counter++;
else if(counter == 1)
{
/* Action here (flush cache/yield/...)*/
fs_cache_flush();
counter = 0;
  } else {
/* Impossible case */
panic("Counter value bad\n");
}
break;
...
default:
panic("Unknown trap: 0x%x\n", trap_num)
break;
}
...
}
If you want example code in another language let me know and I can change it. I'm assuming you're using C because you tagged your question with OS. It could also make sense to keep your counter on a per process basis (if your operating system supports processes).

Handling exceptions in MQL4

In the Java language one can handle exceptions with a try-catch mechanism.
Does it exist any similar behaviour in MQL4?
This code throws the error 'array out of range' in the Close[bar] expression and I cannot handle it properly.
Any help will be appreciated.
bool isBarClosed( int bar ) {
bool barClosed = true;
double closePrice = Close[bar];
int error = GetLastError();
if ( error == 4202 ) {
barClosed = false;
}
return barClosed;
}
No.
MQL4 has no syntax support for a construct alike a try/except/finally or try/catch use-case in python / java and alike languages.
How to handle exceptions?
Assume there are no compile-time errors.
The run-time errors are hard to be handled, some even cause the software to crash.
One could and rather shall proactively sanitize the MQL4-code with a due type-checking and use-case pre-validations so as to prevent exceptions.
Exceptions to this are dbPool operations, which may, under some conditions, "legitimately" fail to yield an expected result.
A GetLastError() ( if it was cleared a-priori the exception itself ) may serve as an almost-post-mortem identification, not as an exception handler.
4202? Not your problem, Bro'
_LastError == 4202 ... does not explain the trouble <<< stdlib.mqh
4202
ERR_OBJECT_DOES_NOT_EXIST
Object does not exist
Your problem seems to be related with bar "pointing" outside of the TimeSeries-reverse-stepping-index of Close[] values.
0 <= aBarPtrIDX < Bars
Next target? A Close[aBarPtrIDX] misconcept
After some time spent in MQL4 domain, one becomes familiar with a few contradicting facts. One of potential surprises is, that a current bar, the
"hot-zero" [0], contains Close[0] == Bid during it's all live-life-span.
After the running bar gets terminated by aNewBarEVENT ( signalled by a Volume[0] == 1 ( or Volume[0] < aPreviousVolume_0 -- a safer mode for a case, the MQL4-loosely-coupled event-loop has missed a few quote-arrivals during it's busy-episode )), the Close[1] represents the last-visited price during the respective Bar-period and Close[0] keeps surfing on the always-changing Bid price

Non-blocking MPI communication from every node to every other node fails

I'm trying to implement a data transfer using Fortran 90 and MPI in which every node sends a specific buffer to every other node, i.e. for N nodes I have N-1 buffers to be sent, each one with a different content specific to the recipient node. This involves a double loop and non-blocking send/recv calls; here's the code:
program a2a
implicit none
include "mpif.h"
integer, parameter :: ILEN=4
integer :: nn,i,j,me,ierr
integer :: status(MPI_status_size)
integer, allocatable :: sndv(:),rcvv(:),ireq(:)
call MPI_init(ierr)
call MPI_comm_size(mpi_comm_world,nn,ierr)
nn=nn-1
call MPI_comm_rank(mpi_comm_world,me,ierr)
allocate(sndv(0:nn),rcvv(0:nn),ireq(0:nn))
do i=0,nn
sndv(i)=10*me+i
rcvv(i)=0
end do
do i=0,nn
if (i == me) then
do j=0,nn
if (i == j) cycle
call MPI_isend(sndv(j),ILEN,MPI_byte,j,1000+j,MPI_comm_world,ireq(j),ierr)
write(*,*) 1000+j,'Send - #',me,' -> #',j,': ',sndv(j),ireq(j)
end do
else
do j=0,nn
if (i == j) cycle
call MPI_irecv(rcvv(j),ILEN,MPI_byte,j,1000+j,MPI_comm_world,ireq(j),ierr)
write(*,*) 1000+j,'Recv0 #',i,' -> #',j,': ',rcvv(j),ireq(j)
end do
end if
end do
do j=0,nn
if (me == j) cycle
call MPI_wait(ireq(j),status,ierr)
write(*,*) 1000+j,'Recv1 #',me,' -> #',j,': ',rcvv(j),ireq(j)
end do
call MPI_barrier(MPI_comm_world,ierr)
do i=0,nn
write(*,*) 'Recv2 #',i,' -> #',me,': ',rcvv(i)
end do
call MPI_finalize(ierr)
end program a2a
The expected result for a run with just two nodes is that node 0 sends "1" to node 1 and node 1 sends "10" to node 0. The actual result is that nothing seems to be sent, although there is no deadlock and the tags and request numbers seem to be correct. What is wrong here?
Thomas
Look at the MPI_irecv command, and what it should be:
MPI_irecv(rcvv(j),ILEN,MPI_byte,j, 1000+j,MPI_comm_world,ireq(j), ierr)
MPI_irecv(sendBuf, len,type, source, tag, comm, request, ierr)
Specifically, you have set your source variable to be j. If you look at the MPI_isend command, however, the processor that is sending the information is processor i (the send only occurs if i == me). Change the source in your MPI_irecv command to i and it should work fine.
That said, this seems like a perfect use case for an MPI_Alltoall command, why don't you use that instead?
Turns out, the whole approach of the program was flawed, because for tests with more than 2 nodes, deadlocks occurred and/or buffers got mixed up. For the record, below is a new program that seems to do the job correctly.
#wolfPack88 concerning the suggestion to use MPI_Alltoallv: yes, in principle that would do it. However, in my actual problem, for which this is just a test, it is even more complicated in that the nodes involved in the whole task can be only a fairly small subset of all nodes of the run. In that case MPI_Alltoallv might be overkill and would presumably cause unnecessary communication. Still, pointing me to the mistake with the source finally opened my eyes to the root of the trouble, so thanks for that.
Here's the code:
program a2a
implicit none
include "mpif.h"
integer, parameter :: ILEN=4
integer :: nn,i,me,ierr
integer :: status(MPI_status_size)
integer, allocatable :: sndv(:),rcvv(:),ireq(:)
integer, external :: isend,irecv,mynode,numnodes
call MPI_init(ierr)
call MPI_comm_size(mpi_comm_world,nn,ierr)
nn=nn-1
call MPI_comm_rank(mpi_comm_world,me,ierr)
allocate(sndv(0:nn),rcvv(0:nn),ireq(0:nn))
do i=0,nn
sndv(i)=10*me+i
rcvv(i)=0
end do
do i=0,nn
if (i == me) cycle
call MPI_irecv(rcvv(i),ILEN,MPI_byte,i,1000*i+me,MPI_comm_world,ireq(i),ierr)
end do
do i=0,nn
if (me == i) cycle
call MPI_isend(sndv(i),ILEN,MPI_byte,i,1000*me+i,MPI_comm_world,ireq(i),ierr)
write(*,*) 1000*me+i,'Send - #',me,' -> #',i,': ',sndv(i),ireq(i)
end do
do i=0,nn
if (me == i) cycle
call MPI_wait(ireq(i),status,ierr)
end do
call MPI_barrier(MPI_comm_world,ierr)
do i=0,nn
if (i /= me) write(*,*) 'Recv2 #',i,' -> #',me,': ',rcvv(i)
end do
call MPI_finalize(ierr)
end program a2a

Why called "ABA_problem"?

today I knew ABA problem.
http://en.wikipedia.org/wiki/ABA_problem
By the way, suddenly, i just like to know why called "ABA" problem? abbreviation?
ABA is not an acronym and is a shortcut for stating that a value at a
shared location can change from A to B and then back to A :)
As far as I know, the problem is related to threads interleaving. So I think it comes as a short textual representation of interleaving. First, run a thread A, then switch to thread B, then get back to thread A.
Assume you have two threads, and one is checking a global character whether there's new data:
char flag = 'n';
void alarms(){
while(true){
if(flag == 'f'){
start_fire_alarm();
}
/* ... some other things, including some waiting ...*/
}
}
void sensors(){
while(true){
if(sensor_alerts_fire()){
flag = 'f';
} else {
flag = 'n';
}
}
}
Now alarm checks the flag, sees 'n' and everything is fine. Suddenly, a fire starts, and sensors sets the flag to 'f'. But before the operating system gives alarm some time to react, the physical sensors break, and they don't alert the fire anymore. sensors() sets the flag to 'n' again, the operating system gives alarm() some time and nothing happens.
This is the ABA problem (well, in our case NFN). You don't notice in the first thread that your shared value has changed in-between, although this could be critical. Note that you can exchange char with some atomic type and all assignments/tests with atomic ones, the problem would still be the same.

Binding using std::bind vs lambdas. How expensive are they?

I was playing with bind and I was thinking, are lambdas as expensive as function pointers?
What I mean is, as I understand lambdas, they are syntactic sugar for functors and bind is similar. However, if you do this:
#include<functional>
#include<iostream>
void fn2(int a, int b)
{
std::cout << a << ", " << b << std::endl;
}
void fn1(int a, int b)
{
//auto bound = std::bind(fn2, a, b);
//static auto bound = std::bind(fn2, a, b);
//auto bound = [&]{ fn2(a, b); };
static auto bound = [&]{ fn2(a, b); };
bound();
}
int main()
{
fn1(3, 4);
fn1(1, 2);
return 0;
}
Now, if I were to use the 1st auto bound = std::bind(fn2, a, b);, I get an output of 3, 4
1, 2, the 2nd I get 3, 4
3, 4. The 3rd and 4th I get output like the 1st.
Now I get why the 1st and 2nd work that way, they are getting initialised at the beginning of the function call (the static one, only the 1st time it is called). However, 3 and 4 seem to have compiler magic going on where the generated functors are not really creating references to the enclosing scope's variables, but are actually latching on to the symbols whether or not it is initialised only the first time or every time.
Can someone clarify what is actually happening here?
Edit: What I was missing is using static auto bound = std::bind(fn2, std::ref(a), std::ref(b)); to have it work as the 4th option.
You have this code:
static auto bound = [&]{ fn2(a, b); };
Assignment is done only first time you are invoking this function because it's static. So in fact it's called only once. Compiler creates closure when you are making lambdas, so references to a and b from first call to fn1 was captured. It's very risky. It may lead to dangling references. I'm surprised it didn't crashed since you are making closure from function parameters passed by value - to local variables.
I recommend this excellent article about lambdas: http://www.cprogramming.com/c++11/c++11-lambda-closures.html .
As a general rule, only use [&] lambdas when your closure is going to go away by the end of the current scope.
If it is going to outlast the current scope, and you need by-reference, explicitly capture the things you are going to capture, or create local pointers to the things you are going to capture and capture them by-value.
In your case, your static lambda code is full of undefined behavior, as you [&] capture a and b in the first call, then use it in the second call.
In theory, the compiler could rewrite your code to capture a and b by value instead of by reference, then call that every time, because the only difference between that implementation and the one you wrote occurs when the behavior is undefined, and the result will be much faster.
It could do a more efficient job by ignoring your static completely, as the entire state of your static object is undefined after you leave scope the first time you call, and the construction has no visible side effects.
To fix your problem with the lambdas, use [=] or [a,b] to introduce the lambda, and it will capture the a and b by value. I prefer to capture state explicitly on lambdas when I expect the lambda to persist longer than the current block.

Resources