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

Search Discussions

  • Piet van Oostrum at Jun 19, 2009 at 8:53 am

    Vishal Shetye (VS) wrote:
    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.
    --
    Piet van Oostrum <piet at cs.uu.nl>
    URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
    Private email: piet at vanoostrum.org
  • Vishal Shetye at Jun 22, 2009 at 6:27 am
    Thanks.

    - vishal
    -----Original Message-----
    Sent: Friday, June 19, 2009 3:15 PM
    To: python-list at python.org
    Subject: Python-list Digest, Vol 69, Issue 214

    Message: 6
    Date: Fri, 19 Jun 2009 10:53:27 +0200
    From: Piet van Oostrum <piet at cs.uu.nl>
    To: python-list at python.org
    Subject: Re: Help: Group based synchronize decorator
    Message-ID: <m2zlc4r4e0.fsf at cs.uu.nl>
    Content-Type: text/plain; charset=us-ascii
    Vishal Shetye (VS) wrote:
    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.
    --
    Piet van Oostrum <piet at cs.uu.nl>
    URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
    Private email: piet at vanoostrum.org
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedJun 18, '09 at 7:27p
activeJun 22, '09 at 6:27a
posts3
users2
websitepython.org

2 users in discussion

Vishal Shetye: 2 posts Piet van Oostrum: 1 post

People

Translate

site design / logo © 2022 Grokbase