FAQ
Hi,

I have a common question about locks:

class SetPointer
{
private:
void *ptr;

MY_LOCK lock;


public:
void SetPointer(void *p)
{
Lock(this->lock);
this->ptr = p;
}

void *GetPointer()
{
Lock(this->lock);
return this->ptr;
}
};


Just a question, is this lock redundant, when the Pointer can be set/
get from different threads?
Thanks a lot!! Bye, moerchendiser2k3

Search Discussions

  • Ben Finney at Mar 20, 2010 at 2:24 am

    moerchendiser2k3 <googler.1.webmaster at spamgourmet.com> writes:

    I have a common question about locks:
    You'd be best to ask in a forum related to the language you're using.
    This (?comp.lang.python?) is a forum for users of the Python language.

    --
    \ ?If you can do no good, at least do no harm.? ?_Slapstick_, |
    `\ Kurt Vonnegut |
    _o__) |
    Ben Finney
  • Chris Rebert at Mar 20, 2010 at 2:25 am

    On Fri, Mar 19, 2010 at 6:58 PM, moerchendiser2k3 wrote:
    <question about using locks in C++ snipped>

    Thanks a lot!! Bye, moerchendiser2k3
    This is the **Python** mailinglist/newsgroup; and your question isn't
    about Python.

    The C++ one is over there:
    http://groups.google.com/group/comp.lang.c++.moderated/topics

    Regards,
    Chris
  • MRAB at Mar 20, 2010 at 2:31 am

    moerchendiser2k3 wrote:
    Hi,

    I have a common question about locks:

    class SetPointer
    {
    private:
    void *ptr;

    MY_LOCK lock;


    public:
    void SetPointer(void *p)
    {
    Lock(this->lock);
    this->ptr = p;
    }

    void *GetPointer()
    {
    Lock(this->lock);
    return this->ptr;
    }
    };


    Just a question, is this lock redundant, when the Pointer can be set/
    get from different threads?
    Thanks a lot!! Bye, moerchendiser2k3
    1. That's C++. What does it have to do with Python?

    2. The value you're accessing is a simple pointer which you're either
    setting or getting, so a lock shouldn't be necessary.

    3. You're locking, but never unlocking. The sequence should be: lock, do
    stuff, unlock.
  • Gabriel Genellina at Mar 20, 2010 at 3:09 am
    En Fri, 19 Mar 2010 23:31:23 -0300, MRAB <python at mrabarnett.plus.com>
    escribi?:
    moerchendiser2k3 wrote:
    class SetPointer
    {
    private:
    void *ptr;
    MY_LOCK lock;
    public:
    void SetPointer(void *p)
    {
    Lock(this->lock);
    this->ptr = p;
    }
    3. You're locking, but never unlocking. The sequence should be: lock, do
    stuff, unlock.
    Just FYI: C++ doesn't have try/finally, and such behavior is usually
    emulated using a local object. When it goes out of scope, it is
    automatically destroyed, meaning that the object destructor is called.
    Whatever you would write in a "finally" clause, in C++ goes into a
    destructor.

    Of course C++ guys would never say they're "emulating" try/finally,
    instead they declare RAII as *the* Only and Right Way :)

    --
    Gabriel Genellina
  • MRAB at Mar 20, 2010 at 3:38 am

    Gabriel Genellina wrote:
    En Fri, 19 Mar 2010 23:31:23 -0300, MRAB <python at mrabarnett.plus.com>
    escribi?:
    moerchendiser2k3 wrote:
    class SetPointer
    {
    private:
    void *ptr;
    MY_LOCK lock;
    public:
    void SetPointer(void *p)
    {
    Lock(this->lock);
    this->ptr = p;
    }
    3. You're locking, but never unlocking. The sequence should be: lock, do
    stuff, unlock.
    Just FYI: C++ doesn't have try/finally, and such behavior is usually
    emulated using a local object. When it goes out of scope, it is
    automatically destroyed, meaning that the object destructor is called.
    Whatever you would write in a "finally" clause, in C++ goes into a
    destructor.

    Of course C++ guys would never say they're "emulating" try/finally,
    instead they declare RAII as *the* Only and Right Way :)
    Lock() doesn't look like a declaration, but a function call (although
    it's been a while since I last did C++!).

    In the past I've written some C++ code where try..finally... would've
    been useful... *sigh*
  • Alf P. Steinbach at Mar 20, 2010 at 4:15 am

    * MRAB:
    Gabriel Genellina wrote:
    En Fri, 19 Mar 2010 23:31:23 -0300, MRAB <python at mrabarnett.plus.com>
    escribi?:
    moerchendiser2k3 wrote:
    class SetPointer
    {
    private:
    void *ptr;
    MY_LOCK lock;
    public:
    void SetPointer(void *p)
    {
    Lock(this->lock);
    this->ptr = p;
    }
    3. You're locking, but never unlocking. The sequence should be: lock, do
    stuff, unlock.
    Just FYI: C++ doesn't have try/finally, and such behavior is usually
    emulated using a local object. When it goes out of scope, it is
    automatically destroyed, meaning that the object destructor is called.
    Whatever you would write in a "finally" clause, in C++ goes into a
    destructor.

    Of course C++ guys would never say they're "emulating" try/finally,
    instead they declare RAII as *the* Only and Right Way :)
    Lock() doesn't look like a declaration, but a function call (although
    it's been a while since I last did C++!).
    Right. But the OP is clearly a beginner who has yet to learn conventions (like
    all uppercase reserved for macros) and good versus bad programming constructs
    (like using void*), and who is even confusing C++ with Python. So it might just
    be that 'Lock' is a macro, and then it can expand to anything.

    In the past I've written some C++ code where try..finally... would've
    been useful... *sigh*
    Check out Marginean and Alexandrescu's ScopeGuard. Old DDJ-article. For MSVC you
    may want to change use of __LINE__ in that code, to MS-specific __COUNTER__.

    Fwiw. I can't remember ever needing 'finally' in C++ code.

    It indicates a lack of encapsulation of entitites that should clean up
    themselves. Simple smart pointers etc. can help. E.g., check out Boost library.


    Cheers & hth., even if a little off-topic,

    - Alf

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedMar 20, '10 at 1:58a
activeMar 20, '10 at 4:15a
posts7
users6
websitepython.org

People

Translate

site design / logo © 2022 Grokbase