lkml.org 
[lkml]   [2000]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: deadlock avoidance?
On Wed, Dec 08, 1999, Davide Libenzi <dlibenzi@maticad.it> wrote:
> Wednesday, December 08, 1999 1:53 AM
> 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?

JE


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans