06-05-2013 09:42 AM
The VIs must be re-entrant - some of our systems have dozens of instances of 'Child'; if they were not re-entrant the system would have a bottleneck in the the non-re-entrant VIs.
The example I provided is a simplification of the problem that I would resolve with overloading if it were available; it does not describe the requirements I was trying to solve. A simplification of the requirements is that given a class, enhance it to allow a client to (a) setValue, or (b) setValue and lock that value until done. A design constraint is that I am not allowed to change the given class.
06-05-2013 06:55 PM
This may not be what you are after, but here goes anyway:
Have you considered using references to manage your locking/unlocking functionality.
It is in-built the the In-Place structure.
There are many tricks, traps and limitations (References don't passively polymorph - You have to do geric/specific type conversion),
06-06-2013 09:16 AM
Our team finished reviewing the example, and the code that it was based on. The resulting attached project (zip) is what we plan to go with for now, and the future (until LV comes out with overloading). The pattern is built up with two semaphores - one on the instance data manage the availability of the resource represented by the instance, and one 'on-the-wire' to indicate that if the instance semaphore is held, that it is OK to proceed because the semaphore is owned by the current thread of control.
This kind of semaphore pattern is known to us in other applications as a 'thread-safe' semaphore. This says that once the thread of control has entered into the instance and the instance has acquired a lock, that any method inside the instance can do what it wants with the instance until the lock is released.
06-06-2013 09:17 AM
Here's the project.