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