I just want to know the meaning of optional Cancellation point. Like we have mandatory cancellation point which means cancellation point shall occur when any of the functions that comes under mandatory cancellation points is called in a thread. So, is it like for optional one , cancellation point may occur or may not. I have check SO for this but i didn't find any exact answer regarding this.
POSIX requires certain functions to be a cancellation point and says cancellation points may occur in certain functions (optional cancellation points). You can read the entire list of mandatory and optional cancellation points from the manual pthreads(7):
Cancellation points
POSIX.1 specifies that certain functions must, and certain other
functions may, be cancellation points. If a thread is cancelable,
its cancelability type is deferred, and a cancellation request is
pending for the thread, then the thread is canceled when it calls a
function that is a cancellation point.
Related
Consider the simplest ExpansionRegion of mode stream. According to UML Documentation (16.12 Expansion Regions)
If the value [of mode] is stream, there is exactly one expansion execution, and element values are offered to this execution in a stream from each collection. That is, each element of a collection on an input ElementNode is offered separately as a token, one by one, on all outgoing ActivityEdges from the ExpansionNode
But this ExpansionRegion will never end! As soon as all tokens from input ExpansionNode are processed, Do something will be waiting indefinitely for a token from input, which will never come! How do I terminate this ExpansionRegion?
Update: it seems the only solution I could find is the following (but I'm not sure, see below) :
When there are no more tokens available from input then the control token from Do something is not accepted by Do something through C.3-C.4-C.2 path since according to 16.2.3.4 Actions and Pins in Activities
Executing an Action in an Activity requires all of its InputPins to be offered all necessary tokens, as specified by their
minimum multiplicity
and according to 15.2.3.2 Activity Nodes
When an ActivityNode begins execution, tokens are
accepted from some or all of its incoming ActivityEdges and a token is placed on the node.
so it seems reasonable to conclude from the above that Action (i.e. Do something) will not accept a control token if it is not able to execute so Decision node will pass the token to control flow C.5 since it has "else" guard and according to 15.3.3.6 Decision Nodes:
For use only with DecisionNodes, a predefined guard “else” represented as an Expression with “else” as its operator and no operands) may be used for at most one outgoing edge. This guard evaluates to true only if the token is not accepted by any other outgoing edge from the DecisionNode.
Update 2: Is the loop (C.1-C.2-C.3) required? It seems to me the answer is "yes" because without it Do something would process just one object token! I.e. Do something would receive a single control token at the ExpansionRegion's invocation according to 15.2.3.6 Activity Execution
When an Activity is first invoked, none of its nodes other than input ActivityParameterNodes will initially hold any tokens. However, nodes that do not have incoming edges and require no input data to execute are immediately enabled. A single control token is placed on each enabled node and they begin executing concurrently. Such nodes include ExecutableNodes (see sub clause 15.5) with no incoming ControlFlows and no mandatory input data and InitialNodes (see sub clause 15.3).
and according to 15.5.3.1 Executable Nodes
When an ExecutableNode completes an execution, the control token representing that execution is removed from the
ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode.
Are there any clarification in UML Documentation saying that control token could "stay" on Do something (without the loop) and re-enable its execution to process next object token?
You seem to think that you modeled a deadlock. Actually, UML Activities cannot have deadlocks by definition. The execution of all action containers (Activitys and StructuredActivityNodes with their subtypes) ends when none of the contained actions is enabled.
StructuredActivityNode: A StructuredActivityNode completes execution according to the same rules as for the completion of the execution of an Activity, including terminating execution due to an ActivityFinalNode.
Activity: The execution of an Activity with no streaming Parameters completes when it has no nodes executing and no nodes
enabled for execution, or when it is explicitly terminated using an ActivityFinalNode.
After processing the last element in the input collection, no action is enabled anymore and therefore, the expansion region ends and offers the output collection to the outgoing object flow. Therefore, the initial node and all the control flows are not needed.
Having said that, it is possible, that you need control flows, because you have additional actions. Let's say you need to initialize the system before the first execution and Do something else after each execution of Do something. Your first example works well for this. Just place initialize on C.1 and Do something else on C.3.
Your second solution could be used, if you have to do some cleanup before leaving the expansion region. Just place it on C.5. I was not aware, that this would work, but after rereading the specification text cited by you, I agree that it is working.
It seems like you missed the point that object tokens are sufficient to trigger an action - without any need for a control token.
UML 2.5 p. 374:
15.2.3.4 Object Flows
Object tokens pass over ObjectFlows, carrying data through an Activity via their values, or carrying no data ( null tokens). A null token can still be passed along an ObjectFlow and used like any other token. For example, an Action can output a null token to explicitly indicate that it did not produce an optional value, and a downstream DecisionNode (see sub clause 15.3) can test for this and branch accordingly.
So once you get rid of the start node and the superfluous control structures you will get the desired behavior: the action starts with receiving an object and ends when emitting the resulting object.
I could not find a full fledged example on the fly, but that picture illustrates it well enough:
Longer explanation
P. 478 of UML 2.5: (please look into the specs for more details)
16.12 Expansion Regions
16.12.1 Summary
An ExpansionRegion is a StructuredActivityNode that executes its contained elements multiple times corresponding to elements of an input collection.
[...]
16.12.3 Semantics
An ExpansionRegion is a StructuredActivityNode that takes as input one or more collections of values and executes its contained ActivityNodes and ActivityEdges on each value in those collections. If the computation produces results, these may be collected into output collections. The number of output collections can differ from the number of input collections.
[...]
16.12.4 Notation
An ExpansionRegion is shown as a dashed rounded box with one of the keywords «parallel», «iterative» or «stream» in the upper left corner (see Figure 16.48). Input and output ExpansionNodes are drawn as small rectangles divided by vertical bars into small compartments.
[...]
As you can see, the expansion region is a "simple" action that takes an object and returns another. As such it's like any simple action with an input pin like shown above in my answer. That means it will start upon receipt of an object and emit an (eventually empty) object when it's done.
Is it possible to cancel a scheduled operation in azure function durable entity ? Below is an example code.I want to cancel the call to operation "DeviceTimeout"after it is scheduled.
Entity.Current.SignalEntity(Entity.Current.EntityId, DateTime.UtcNow.Add(TimeSpan.FromSeconds(30)), nameof(DeviceTimeout));
Unfortunately not. There is an open issue requesting this ability but afaik it has not been implemented yet:
I can' think of a very straightforward API to provide this. One approach would be to include some sort of unique identifier for the signal so that a cancellation request can be precisely matched to the signal being cancelled. But there are some open questions on what exactly the implementation would have to guarantee, and whether that can lead to new issues. For example, would we need to store a cancellation request that we can't match to a signal until such a signal arrives? what if it never arrives?
I suppose the next best thing is to just exit immediately once the operation is executed.
Customers can pay for an order instantly or later. When the order is pay-later, I want to draw a notation that signifies that the customer must pay within two-day time in an activity diagram. If the customer does not pay within two-day time, the system will mark the order as canceled.
In this attached image, the first swimlane is for the actor Customer, and the second swimlane is for the actor System. I created a time event notation that signifies that the customer must pay within 48 hours. Then, I placed the merge/branch node on the customer swimlane to signify that the customer is the actor that must make the payment.
The issue that I thought of about my current diagram is that someone might misunderstand the time event notation. Someone might understand the notation as a sign that the system will always wait 48 hours before marking the order as canceled or awaiting shipment. In reality, the system will mark the order as awaiting shipment as soon as the customer pays. However, if the customer doesn't pay after 48 hours, the system will mark the order as canceled.
How can I draw a better diagram to signify the above description?
An accept time event action (e.g. an AcceptEventAction with a single TimeEvent trigger) cannot have an input flow, so your diagram is invalid, and then does not show what you want.
The guards of the flow after a Decision must be written between brackets ([]).
I placed the merge/branch node on the customer swimlane to signify that the customer is the actor that must make the payment.
but this is check by the system independently of the customer, so this is wrong / unclear
The fact the two actions creating order are not in the customer swimlane is also wrong / unclear for me
After the action create an order with the awaiting payment status you can create a new timer dedicated to the current order of the customer. In case a customer pays before 2 days the corresponding timer is deleted.
But that can produce a lot of timers, you can also memorize the current order more timeout in a fifo and you have a unique timer. In case a customer pays before 2 days the corresponding order is removed from the fifo.
That unique timer can periodically check the memorized orders, but that pooling wake-up the system even when nothing must be done.
That unique timer can be started when a first order is memorized, then when the system wake-up it manages the too older orders, then if the fifo become empty the timer is stopped else it is updated depending on the delay of the first (older) order in the fifo
Per #qwerty_so's comment, I have decided to use an interruptible region. This interruption trigger of this region is the system accepting payment. Here's the new diagram.
EDIT
As per #bruno's comments and #Axel Scheithauer's comments, I have cropped the more complete image of my activity diagram. An Accept Time Event Action seems to be able to have incoming edges/flows, contrary to #bruno's comments. Furthermore, I believe that the incomplete screenshot was what caused confusion in my diagram.
I also revised my diagram so that the interruptible region's signal comes from the Accept Time Event Action instead of Accept Event Action.
Diagram 1:
Diagram 2:
I have an operation/task that I need to run, which is triggered by an event getting fired (I don't think this last thing is really important).
Thing is, this task is composed of several io operations, network calls mostly. Also, I would like to run this task atomically, start to end, one at the time, newer tasks should not start until the current one finishes.
I would normally do this using a critical section of some kind, but I don't think there's such a concept in js or the node base lib. How do you suggest I should handle a case like this?
thanks
EDIT: I've seen the "critical sections are not needed, this is single threaded" opinion several times in different posts and I think that is only partially true, it only applies to synchronous actions.
Suppose the typical scenario for which critical sections are used, you need to do 2 things A) check for the validity of a condition, B) apply an action only if A is either true or false, an action that would flip the condition. You don't want 2 threads to arrive to the conclusion that A is false at the same time, and that B should be done, so you wrap A and B in a critical section to make them atomic. In node.js, if A in synchronous then you are fine, no other thread will be running and you can do B safely. But if A is async, before it's callback fires, another event for A might show up on the event queue, before the first one get's it's B executed.
As mscdex noted a queue would be preferable, Async has queue() that would be able to handle the scenario you described. To guarantee the 'critical section' feel just set concurrency: 1 for the queue.
I am studying a UML sequence Diagram and I came across method invocation so, I have noticed that there are two ways to make invocation for the method-behavior in Unified Modeling Language(UML) which is signal and message but I don't know how to specify which one of them and based on what ?I mean When to use message and when to use signal because I think this is a very important design decision and should be well chosen?
It actually is, but I think the terminology that you use is not very acurate (message and signal). All kind of communication between two objects in sequence diagram is considered to be a message.
However, there are two basic types of messages - synchronous and asynchronous.
A usual method invocation, when a method invoker waits blocked till the method execution is over is synchronous invocation, a synchronous message. The invoker will receive the return value from the invoked method and continue its own execution.
In consequence, here is only one thread of execution.
There is also a asynchronous communication, when an object somehow sends a message to another object and immediatelly continues its execution without waiting. Example of this are SMS message, UDP package send, etc.
Here, there are two independent threads of execution.
By a signal it is often ment - asynchronous message send.
Kirill Fakhroutdinov's page http://www.uml-diagrams.org/sequence-diagrams.html explains message as
Messages by Action Type
..A message reflects either an operation call and start of execution or a sending and reception of a signal...
Besides the synchronous/asynchronous nature of messages it also points to "send signal action" as used in activity diagrams
Asynchronous Signal
..Asynchronous signal message corresponds to asynchronous send signal action..
To me an important distinction in modeling messages vs signals is the unicast/multicast(broadcast) semantics. Signal specifically can be send from one place (with all necessary arguments packed) and received at multiple places
Sequence diagrams allow modeling of the multicast behavior using the found message and lost message concept
(I'm not 100% sure but I believe I'm close)
EDIT: adding reference to more formal explanation backing my argument that signals have something to do with unicast/multicast(broadcast) as response to comment by #Aleks
The book "The Unified Modeling Language Reference Manual" by James Rumbaugh, Ivar Jacobson, Grady Booch, Copyright © 1999 by Addison Wesley Longman, Inc. explains the difference between messages and signals e.g. using following words
Message..Semantics
..A message is the sending of a signal from one object (the sender) to one or more other objects (the receivers), or it is the call of an operation on one object (the receiver) by another object (the sender or caller). The implementation of a message may take various forms...
Signal event
..
A signal has an explicit list of parameters. It is explicitly sent by an object to another object or set of objects. A general broadcast of an event can be regarded as the sending of a signal to the set of all objects, although..
..
Signals are explicit means by which objects may communicate with each other asynchronously. To perform synchronous communication, two asynchronous signals must be used, one in each direction of communication..
EDIT: adding the 3 different message notations as they are visualized by Enterprise Architect
Note that due to the asynchronous and multicast nature of signals (as mentioned above) the corresponding notation does not include the "Return Value" part