Re: Method combinations as a design pattern for locking

On 12/18/2013 02:00 AM, Bruce Hoult wrote:
> 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.

Yes, that is similar to what i thought. The entry point can probably be
a "define function".

Implementing the method combination that CLOS uses would require
querying the applicable methods on the around GF and overriding the
next-method argument, which I am not sure DFMC would currently optimize
very well.

However, it should also be possible to use "normal" dispatch and define
extra keyword arguments (primary-method: in around methods) for relating
methods.

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

One reason for my tendency to generalize this is that wrapping runtime
macros is not always trivial and requires some repetition.

However, for locking specifically, "define locked-generic" might be
sufficient and would also maximize clarity of exported names.

I am currently playing with a few variants of this in code.

> 
> On Wed, Dec 18, 2013 at 1:38 PM, Ingo Albrecht <[email protected]
> <mailto:[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] <mailto:[email protected]>
>     https://lists.opendylan.org/mailman/listinfo/hackers
> 
> 
> 
> 
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers
> 
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers