Real OO Semaphore operations

Real OO Semaphore operations

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.

6 Comments
Account_Closed
Not applicable
 
Micro Focus Expert
Micro Focus Expert

Hi DanC,

Indeed community content already exists. Can you detailed a bit why the existing content is not working and what is the perfect solution you envision?

Thank you,

Lucian 

Micro Focus Expert
Micro Focus Expert

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
  4. THEY INCLUDE NO DEADLOCK DETECTION
  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

 

Dennis Handly Acclaimed Contributor.
Acclaimed Contributor.

> Acquiring a lock should be reentrant

 

Probably a better description would be recursive.

Micro Focus Expert
Micro Focus Expert
Dennis Handly Acclaimed Contributor.
Acclaimed Contributor.

@David Fidler

 

Yes I saw that article.  But google has 2 to 1 references to recursive.  🙂

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.