Idea ID: 1635598

Real OO Semaphore operations

Status : Under Consideration
Under Consideration
See status update history
over 3 years ago

Would like to see HPE-OO have true Semaphore operations that would work globally across multiple flows and would suspend on an acquire (P) operation. Community content is available for this but it should be inherit in the product itself.

  • We are considering this idea for a future enhancement in OO.


    Yes I saw that article.  But google has 2 to 1 references to recursive.  :-)

  • > Acquiring a lock should be reentrant


    Probably a better description would be recursive.

  • Because the content that exists is outdated and is no longer really fit for purpose.  It has the following issues:

    1. The supplied examples are not re-entrant
    2. They do not block the process; they require that the flow busy-waits, which fills up my database with a bunch of unnecessary step summary information (because it's busy waiting and looping through a bunch of steps until it gets the lock)
    3. It requres that a new flow be executed just to acquire and the lock and then another flow needs to be executed to release the lock
    5. Most importantly, concurrency is not built into the OO "language".  All modern languages supply the fucntionality for Locks, Mutexes and [Counting] Semaphores.  The current "semaphores-cp.1.2.0.jar" content just provides some examples on how to achieve it.  It's not really usuable content.   OO developers should not be hacking around and building a concurrency model when OO should already have one.

    OO should just provide the following steps :

    • Create Lock/Mutex/Semaphore,
    • Acquire Lock/Mutex/Semaphore
    • Release Lock/Mutex/Semaphore
    • Delete Lock/Mutex/Semaphore. 

    It should also satisfy the following requirements:

    • Acquiring a lock should be reentrant
    • Acquire a lock should be based on Execution_ID and Branch_ID, not the Flow UUID
    • Flows should choose whether to block until they acqurie the lock/mutex/semaphore, and the exist status of the Acquire call should say whether the lock was acuired, not acquired or whether it failed (system error)
    • Deadlock detection
    • Support different ordering metchanisms for flows to acquire locks (FIFO, LIFO, Priority, Priority Aging), where FIFO = like a queue, LIFO = like a stack, Priority = flows acquire with a  priority value; higest priority wins; Priority Aging = Flows acquire with a priority value, hiest priority wins except older flow priorities are increased each time another flow acquires the lock (so they don't starve)
    • Optionally, it should support Read/Writer locks