Messages in this thread | | | Date | Tue, 25 Apr 2006 14:04:06 -0400 | From | "Dmitry Torokhov" <> | Subject | Re: 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/
| |