Help: Group based synchronize decorator

[Vishal Shetye]

I want to synchronize calls using rw locks per 'group' and my implementation is similar to
http://code.activestate.com/recipes/465057/
except that I have my own Lock implementation.

All my synchronized functions take 'whatGroup' as param. My lock considers 'group' while deciding on granting locks through acquire.

What I could come up with is:
- decorator knows(assumes) first param to decorated functions is always 'whatGroup'
- decorator passes this 'whatGroup' argument to my lock which is used in acquire logic.

Is it ok to make such assumptions in decorator?
Any suggestions/alternatives?

thanks
vishal
DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

 

[Piet van Oostrum]

VS> I want to synchronize calls using rw locks per 'group' and my implementation is similar to
VS> http://code.activestate.com/recipes/465057/
VS> except that I have my own Lock implementation.

VS> All my synchronized functions take 'whatGroup' as param. My lock considers 'group' while deciding on granting locks through acquire.

VS> What I could come up with is:
VS> - decorator knows(assumes) first param to decorated functions is always 'whatGroup'
VS> - decorator passes this 'whatGroup' argument to my lock which is used in acquire logic.

VS> Is it ok to make such assumptions in decorator?

As long as you make sure that all decorated functions indeed adhere to
that assumption there is nothing wrong with it.