As far as I remember, this was modeled after the Petri nets.

I remember that this part of the specification has changed between my PDF version of the specification (20003 january 6), and by the time the UML 2.0 was finalized in Rational Rose files (which I can’t and won’t handle)

Anyway, to summarize the specification, whilst there can be multiple actions that are able to fire at any single moment in time, UML does not deal with their concurrency. Quoting the spec:

However, the fact that the UML allows for concurrently executing objects does not necessarily imply a distributed software structure. Some implementations may group together objects into a single task and execute sequentially—so long as the behav- ior of the implementation conforms to the sequencing constraints of the specification.

Also, UML doesn’t deal with passing of time, it only deals with requirements about sequence. Again, quote:

The UML does not provide for the specification of a time metric, but only describes sequences of executions.

That said, in a Petri network, when there are one or more executable actions, at least one will have to execute in the next step. The order of execution between these, just as in real life, is undeterminable. It can also be, that given two executable actions, firing one of them will make the other one impossible to fire.

Therefore, in case your action is the only action in the system which is executable (either because others don’t have their sufficient input or because you only have a single control flow), it will be executed in the next step. When does that next step occur, nobody can, and nobody is willing to tell you.

In case you want to get guarantees, consider LTL modeling your UML actions. UML is formal in order to be modelable with LTL.