Re: Method combinations as a design pattern for locking

There are plenty of C libraries that have both foo() and
foo_with_lock_held() functions, generally with the 2nd one only available
within the library.

Note that there is no need for the outer method that takes and releases the
lock to be a GF. It only has to pass on the arguments to the actual generic
function call. The only thing you lose is possible call site optimizations
(whether compile time or runtime). Making it inline (or a function macro)
restores those.

I think generation of the outer, locking, method is best handled with a
macro, probably a variation on (or wrapper of) the standard "define
generic" macro. That's the best (and intended) way to implement such design
patterns in Dylan. Using a convention for the name of the inner method is
fine, and making it a little long and ugly (-with-lock-held) is good as it
is dangerous to extend it without being aware of the implications -- namely
that calling it from somewhere where the lock is not already held leads to
great badness.



On Wed, Dec 18, 2013 at 1:38 PM, Ingo Albrecht <[email protected]> wrote:

> 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
>

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