Monday, January 31, 2000 11:51 PM
Johannes Erdfelt <jerdfelt@sventech.com> wrote :
> > > > > All pid and count modify fall inside 1) a nested lock ( ie. the
task
> > > > > already own the lock : ++lock->count )
> > > > > 2) a lock acquired : lock->pid = getpid() and ++lock->count
> > > >
> > > > The setting is, but not all of the reading.
> > >
> > > There is not test & set operations other than spin_... in my code.
> > > Look at it better and try to find a sequence of operations that stall
it.
> > >
> > > struct s_nested_lock {
> > > spinlock_t lock;
> > > short int pid;
> > > short int count;
> > > };
> > >
> > > #define nested_lock(lock, flags) \
> > > if (lock->pid == getpid()) { \
> > > ++lock->count; \
> > > } else { \
> > > spin_lock_irqsave(&lock->lock, flags); \
> > > ++lock->count; \
> > > lock->pid = getpid(); \
> > > }
> > >
> > > #define nested_unlock(lock, flags) \
> > > if (--lock->count == 0) { \
> > > lock->pid = 0; \
> > > spin_unlock_irqrestore(&lock->lock, flags); \
> > > }
> >
> > Hate to bother you again, but I'm running into some issues.
> >
> > getpid() is no longer implemented in 2.3 and using current->pid
> > sometimes results in 0 which is causing the logic to fail (since we set
> > the pid to 0 if the lock is not acquired)
> >
> > Is there anyway to get a unique pid like number under 2.3 kernels?
>
> I've switched it to using current instead of pid as this atleast allows
> the code to work with a SMP kernel on a UP machine. However I'm far from
> sure this is a safe solution.
Try to use -1 as unlock pid.
Be sure to match lock and unlocks.
Cheers,
Davide.
-- All this stuff is IMVHO- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:06 EST