lkml.org 
[lkml]   [2006]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Compiling C++ modules
    On 4/25/06, Avi Kivity <avi@argo.co.il> wrote:
    > Dmitry Torokhov wrote:
    > >>>>>
    > >>>> No, it's optimized out. gcc notices that &lock doesn't change and that
    > >>>> 'l' never escapes the function.
    > >>>>
    > >>>>
    > >>> "l" that propects critical section gets thrown away???
    > >>>
    > >> Calm down, the storage for 'l' is thrown away, but its effects remain.
    > >>
    > >
    > > Would you mind explaining implemenation details a little bit?
    > >
    > (I don't know how familiar you are with C++ so I'm explaining it from
    > the basics, apologies if I'm repeating things you know)
    >
    > Very often one needs to acquire a resource, do something with it, and
    > then free the resource. Here, "resource" can mean a file descriptor, a
    > reference into a reference counted object, or, in our case, a spinlock.
    > And we want "free" to mean "free no matter what", e.g. on a normal path
    > or an exception path.
    >
    > In C++, you code it as a guard object:
    >
    > struct spinlock_guard {
    > spinlock_guard(spinlock_t *lock) { sl = lock; spin_lock(sl); }
    > ~spinlock_guard() { spin_unlock(sl); }
    >
    > spinlock_t *sl;
    > };
    >

    Oh, I remember now - lock is external wrt the code block it protects
    so you just ensure destructor is called at the exit w/o allocating any
    actual storage.
    Thanks.

    --
    Dmitry
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-04-25 20:06    [W:0.022 / U:32.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site