coordinatedtasksequence allocate bug

the attach model use coordinatedtasksequence,the main code is

"treenode destination = outobject(current,port);
treenode operatorteam = centerobject(current,1);
treenode myts = createcoordinatedtasksequence(operatorteam);
int operator1key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));
int operator2key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));
int operator3key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));
int op1travelkey = insertproxytask(myts, operator1key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
int op2travelkey = insertproxytask(myts, operator2key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
int op3travelkey = insertproxytask(myts, operator3key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
insertsynctask(myts, op1travelkey);
insertsynctask(myts, op2travelkey);
insertsynctask(myts, op3travelkey);
int loadkey = insertproxytask(myts, operator1key, TASKTYPE_FRLOAD, item, current, port,0,0,0);
insertsynctask(myts, loadkey);
insertproxytask(myts, operator1key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertproxytask(myts, operator1key, TASKTYPE_FRUNLOAD, item, destination, opipno(current,port),0,0,0);
insertproxytask(myts, operator2key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertproxytask(myts, operator3key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertdeallocatetask(myts, operator1key);
insertdeallocatetask(myts, operator2key);
insertdeallocatetask(myts, operator3key);

dispatchcoordinatedtasksequence(myts);
return 0;"

but the operator will lock ;
if chang code like this ,the model run well
"
treenode destination = outobject(current,port);
treenode operatorteam = centerobject(current,1);
treenode myts = createcoordinatedtasksequence(operatorteam);
// Only change needed is last parameter. 1 - set to non-blocking.
int operator1key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current), 1);
int operator2key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current),1);
int operator3key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current), 1);
int op1travelkey = insertproxytask(myts, operator1key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
int op2travelkey = insertproxytask(myts, operator2key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
int op3travelkey = insertproxytask(myts, operator3key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
insertsynctask(myts, op1travelkey);
insertsynctask(myts, op2travelkey);
insertsynctask(myts, op3travelkey);
int loadkey = insertproxytask(myts, operator1key, TASKTYPE_FRLOAD, item, current, port,0,0,0);
insertsynctask(myts, loadkey);
insertproxytask(myts, operator1key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertproxytask(myts, operator1key, TASKTYPE_FRUNLOAD, item, destination, opipno(current,port),0,0,0);
insertproxytask(myts, operator2key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertproxytask(myts, operator3key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertdeallocatetask(myts, operator1key);
insertdeallocatetask(myts, operator2key);
insertdeallocatetask(myts, operator3key);

dispatchcoordinatedtasksequence(myts);
return 0;"
i think the Dispatcher should allocate three op to first coordinatedtasksequence then allocate to the second coordinatedtasksequence ,and so on.not allocate two op to one coordinatedtasksequence and allocate one op to the another coordinatedtasksequence. after add "1" to the blocking parameter, when Dispatcherallocate two op to one coordinatedtasksequence and allocate one op to the another coordinatedtasksequence,will the Dispatcher deallocation the ops? i want to flexsim deveolp can tell me the mechanism and why. thank you very much.

i find that i make mistake,can admin move this thread to flexsim Q&A ,thank you

why do not flexsim developer answer me question? thank you very much

i think your problem has some relation with dispatcher. becase every proxytask(pts) in coordinationtasksequence should be allocated in dispather. the first cts works all rightly,but the second and the third cts cound not, because every cts can only allocated one pts at one time. so the problem appeared, the sencond cts can allocated two pts, and the third can allocate one pts.
if you change your codes from
int operator1key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));
int operator2key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));
int operator3key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));
to

int operator1key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current),1);
int operator2key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));
int operator3key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));
you will see more clearly


and the flollowing will make your model run all rightly as the codes in your second model.
int operator1key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current),1);
int operator2key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current),1);
int operator3key = insertallocatetask(myts, operatorteam, getinput(current), getinput(current));

thank you xie ?I know clearly before what you say,that is not the key of the probelm.i think every proxytask(pts) in coordinationtasksequence should FIFO,so the problem will not come out.and you do not answer why change code can run well.

i think the key problem is the order of proxytasks(pts) which were waited to be allocated in dispatcher. if you set the first operator1key without adding "1" to the blocking parameter,then this cts should wait until the first pts be allocated. but the other cts can take the priority to allocate it's first pts for the first cts is in blocking state. so this cts get the second place like following picture.


so the first cts can only allocate two pst and the second can allocate one pst. and the total num of operator is 3. so the two cts are in blocking state.

but if you set the last pst(opetator3key) with adding "1" to the blocking parameter, the situation will be different. three psts in first cts will be allocated one by one.

Maybe you should test a bit more, your problem occurs only with two left products in the queue and you start with more than two in the Queue in the beginning.
If you start the model for example with 6 flowitems, the Team transports 4 flowitems and they freeze, when there are two flowitems left.
The Team transports all flowitems, if you pass new flowitems in scheduled order: Two flow items enter the modell and are transported before or right before new items occure, then the team works until all are sent.
Your problem seems to be a theoretical problem, which you can easily pass by a different entering of flowitems in your modell.
Or you use your second approach. Why do you bother with a theoretical problem, if there is a practical answer.

Jörg

Originally Posted by oliver xie

i think the key problem is the order of proxytasks(pts) which were waited to be allocated in dispatcher. if you set the first operator1key without adding "1" to the blocking parameter,then this cts should wait until the first pts be allocated. but the other cts can take the priority to allocate it's first pts for the first cts is in blocking state. so this cts get the second place like following picture.

Attachment 2155
so the first cts can only allocate two pst and the second can allocate one pst. and the total num of operator is 3. so the two cts are in blocking state.

but if you set the last pst(opetator3key) with adding "1" to the blocking parameter, the situation will be different. three psts in first cts will be allocated one by one.

you are wrong,if you set the same priority or Higher priority to firsrt coordinatedtasksequence three insertallocatetask,the problem will also come out.adding "1" to the blocking parameter should not affect how dispatcher allocate insertallocatetask.blocking parameter should just control coordinatedtasksequence block. if the blocking parameter affect how dispatcher allocate insertallocatetask,that is bad for user.

Hi Lin,

please check, which Task and which Tasksequence the Taskexecuters are in, when the Team freeze. And please do not let us guess, what you already know. Describe what you tested so far. You are an experienced User, so please act as one.

Jörg

hi vogel,
the problem is easy to understand. and this mode is very easy.the three coordinatedtasksequence create at the same time,the insertallocatetask creat some TS at the same time,should FIFO if the TS have the same priority, or according to the priority.this is key point for this problem. thank you.

The model does what it should do:
The insertallocatetask has for the second dispatched coordinated Tasksequence the preempting parameter: 3 - PREEMPT_AND_ABORT_ALL. The Tasksequencequeue and the active Tasksequence are emptied in the Taskexecuter. Every link to any active Tasksequence is destroyed. There are no more task to do. Even the deallocatetasks are gone.

Jörg

if you change code like this

"treenode destination = outobject(current,port);
treenode operatorteam = centerobject(current,1);
treenode myts = createcoordinatedtasksequence(operatorteam);
int operator1key = insertallocatetask(myts, operatorteam, 0, 0);
int operator2key = insertallocatetask(myts, operatorteam, 0, 0);
int operator3key = insertallocatetask(myts, operatorteam, 0, 0);
int op1travelkey = insertproxytask(myts, operator1key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
int op2travelkey = insertproxytask(myts, operator2key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
int op3travelkey = insertproxytask(myts, operator3key, TASKTYPE_TRAVEL, current, NULL, 0,0,0,0);
insertsynctask(myts, op1travelkey);
insertsynctask(myts, op2travelkey);
insertsynctask(myts, op3travelkey);
int loadkey = insertproxytask(myts, operator1key, TASKTYPE_FRLOAD, item, current, port,0,0,0);
insertsynctask(myts, loadkey);
insertproxytask(myts, operator1key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertproxytask(myts, operator1key, TASKTYPE_FRUNLOAD, item, destination, opipno(current,port),0,0,0);
insertproxytask(myts, operator2key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertproxytask(myts, operator3key, TASKTYPE_TRAVEL, destination, NULL, 0,0,0,0);
insertdeallocatetask(myts, operator1key);
insertdeallocatetask(myts, operator2key);
insertdeallocatetask(myts, operator3key);

dispatchcoordinatedtasksequence(myts); "
the problem also come out.

Hello Xu,

if you test your model step by step you will see the behaviour described in the manual:
Every incoming Coordinatedtasksequence (cts) is processed by the coordinator immediately. First the allocatetask in the cts are used to create and dispatch new Tasksequences in the Coordinator. If there is a Taskexecuter available, the Coordinater transferres the first new created Allocatetasksequence to it. Then the next Task of the cts is processed. It is the second Allocatetask. Now the Coordinater creates a new Allocatetasksequence and passes it to the next available Taskexecuter. This works fine with the first cts in the model. It works also fine with the third allocatetask of the first cts.
After that the coordinater receives the second cts. And it is now important, if the tasks are of blocking or non-blocking parameter. Blocking will stop the execution of the cts. The cts will be suspended until any blocking task is successfully executed.
The second cts is processed by the coordinater at once. The first task is an Allocatetask with actived blocking. The coordinater creates a new Allocatetasksequence and passes it. Because there is no Taskexecuter available, the coordinater stores the Allocatetasksequence in its Tasksequencequeue. But the first task of the second cts is not executed successfully. The cts is suspended.
The third cts is received and executed at once. The coordinator creates for the first Task of this cts a new Allocatetasksequence. This Allocatetasksequence is stored again in the Tasksequencequeue, because there is still not any Taskexecuter available. The third cts is suspended.

After the first cts is nearly finished, an Operater of the Operatorteam is deallocated and gets available. The coordinator transfers the first queued-up Tasksequence. Now the first Task of the second cts is successfully passed and the next allocatetask of the second cts is processed by the coordinator. The coordinator creates the next Allocatetasksequence and passes it to the Tasksequencequeue.
The next available Taskexecuter from the Team gets the first queued-up Tasksequence.
And the problem starts here. There are not enough resources to execute two different cts parallel.
The first Operater (Taskexecuter) works on the second cts. The second Operator works on the third cts. But the Operatorteam can't become full with only 3 Operators in the model. And it looks like the operators freeze. They are only waiting to become a full team again.

With the non-blocking parameter set the model works fine because all the Allocatetasksequences are created at once and queued-up in Tasksequencequeue in the order in which the cts enter the coordinator.

That is similar what Oliver Xie has written earlier in his post.

Jörg

you are right , i make sence,thank you very much .