On 1/28/08, David Clark <vdc1048 at tx.rr.com> wrote:
> At 12:25 AM 1/28/2008, you wrote:
> >On 1/28/08, David Clark <vdc1048 at tx.rr.com> wrote:
> > > Ok got an idea here. It has to do with lock_count which associated
> > > with the lock.
> > >
> > > enter_lock():
> > > increments lock count
> > > tries to get the OS lock.
> > >
> > > leave_lock():
> > > decrements lock count
> > > releases the OS lock.
> > > if lock_count==0 and marked for deletion // was intended to be
^^^^^^^^^^^^^^^
I mean there. Since the "if lock_count==0 ..." is evaluated without
protection, other thread may enter execution while the lock is being
destroyed, which leaves us in the same place as the original problem.
> > > deleted elsewhere do it now.
> > > delete lock.
> > >
> >
> >Doesn't the code above potentially have problem, as it checks for
> >lock_count and performs deletion without acquiring the mutex?
>
> Ok with the existing mechanism is clear the delete of the mutex needs to
> be delayed. Because once you block on a mutex the OS expects it to
> be there until unblocked.. Then there is the lesser issue of the release on
> that mutex that comes down further in the existing code.
>
> Well, lock_count becomes now many locks + pending locks.
> The idea is simply to delay the deletion if there is locks or pending
> locks, until the last release is completed.
>
> Now lock_count might need to be more complex to avoid an issue with one
> thread being in destroy_lock() testing lock count and finding 0 while
> thread two
> is in enter_lock() but not yet incrementing the lock.
>
> Is that what your talking about Benny?
>
Frankly I haven't a clue what you're talking about. A working C code
would be much easier to understand than thousand words. :)
cheers,
-benny
