Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-14 11:06:17


--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> William Kempf wrote:
> >
> > --- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> > > William Kempf wrote:
> > > > > create the lock on the heap can't help here.
> > > >
> > > > And why not?
> > >
> > > since you can't protect a.next() in that way.
> >
> > Why not?
> {
> boost::lock* lock = new boost::lock(m);
> for (int i = a.get(); i < 100; a.next())
> {
> <some code>
> delete lock;
> f();
> lock = new boost::lock(m);
> <some code>
> }
> delete lock;
> }
>
> since you can do it just the following way, but this code create
100 lock
> (for safety:-()

I don't follow you. You just showed how the heap WILL work to solve
your problem. The only issue left is performance, since allocations
are expensive, but unsafe_lock<> solves this issue by using placement
new.

> ps. anyway I can agree with csaba, if we don't have lock/unlock on
mutex at
> least we need it on lock (yes this is the unsafe_lock and we loose
compile
> time check and...almost everything safe, but the exception safety).

Again, I don't know why you keep going back to this argument if
you're happy with unsafe_lock<> (which need not even be included in
the library since implementing it is trivial, even though I've
already agreed to it's inclusion).

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk