Method combinations as a design pattern for locking

I would like to find or implement a mechanism akin to CL method
combinations for solving a design pattern issue i have encountered
several times while working in dylan libraries that involve locking or
other forms of resource reservation.

The problem is where to put locking protocol code (with-lock and such)
and their corresponding unwind-protect for generic functions.


Option 1 (which is obviously bad) is repeating the lock (possibly with
a recursive-lock to allow for next-method calls) in every method.
This is what is currently done in a few places, such as libio streams.

Option 2 (which i used as a stopgap) is defining an internal
(non-locking) generic in addition to the outer, locking, generic.
This is what i use in libconcurrency, but it still has to be done
per GF and probably is convention that should be structure.

Both of these options can be complicated slightly by introducing
"unlocked" variants of objects.

In CLOS, it is possible to implement such locking protocols using
an around method on the corresponding generic. Dylan does not have
such a mechanism, possibly because it was thought to be easily
implemented with next-method. This, however, is not very transparent
in the best of circumstances. And its worse for locking.

I would therefore like to ask you all for proposals as to how this
can be dealt with. It is possible to implement this mechanism atop
our current dispatch using just a few macros, but it would imply
"name magic" so the inner GF can be exported for extension, similar
to macros that have "define $foo" magically associated with "$foo-definer".

Greetings
 prom
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers