Re: [SSI] openssi/kernel/cluster/ssi/vproc vp_subr.c, 1.15, 1.16

One thing about the existing macro's for spin locks is that debugging
(sp_owner) cannot be compiled away unlike Linux spinlock debugging.

I think the ATOMIC_READ_INT macro is painful and redundant, and only
useful when porting to another O/S.  More recent code actually avoids
using these macro's - easier on the eyes.

We just haven't got around to cleaning up the exposed sp_lock -
redefining vproc_list_lock as a regular Linux spin lock.  The issue
with the old vproc reference count code causing the bug was in the
design.


On Sun, Feb 8, 2009 at 10:34 AM, John Hughes <[email protected]> wrote:
> Roger Tsang wrote:
>>
>> --- vp_subr.c   3 Feb 2009 06:18:13 -0000       1.15
>> +++ vp_subr.c   8 Feb 2009 02:44:43 -0000       1.16
>> @@ -249,10 +249,7 @@
>>                VPROC_REFCNT_UNLOCK(v);
>>        }
>>  #else
>> -       BUG_ON(READ_ATOMIC_INT(&v->vp_ref_cnt) < 1);
>> -
>> -       if (atomic_read(&v->vp_ref_cnt) == 1)
>> -               might_sleep();
>> +       might_sleep_if(atomic_read(&v->vp_ref_cnt) == 1);
>>  #ifdef VPROC_LIST_SPINLOCK
>>        if (!atomic_dec_and_lock(&v->vp_ref_cnt,
>> &(&vproc_list_lock)->sp_lock))
>>  #else
>>
>
> What's your opinion of the OpenSSI/CI synch.h macros?  Should we be using
> READ_ATOMIC_INT or atomic_read?
>
> I've made an ATOMIC_DEC_AND_LOCK_SPIN_LOCK to avoid exposing the
> sp_lock field of our SPIN_LOCK_T:
>
> #define ATOMIC_DEC_AND_LOCK_SPIN_LOCK(_atomic, _lockp) \
>       ssi_atomic_dec_and_lock_spin_lock(_atomic, _lockp)
>
> static inline int ssi_atomic_dec_and_lock_spin_lock(
>       atomic_t *atomic, SPIN_LOCK_T *lockp)
> {
>       SSI_LOCK_ASSERT_INITED(lockp);
>       SSI_LOCK_ASSERT(lockp->sp_owner != current);
>       SSI_LOCK_ASSERT(!in_interrupt());
>       if (atomic_dec_and_lock(atomic, &lockp->sp_lock)) {
>               lockp->sp_owner = current;
>               return 1;
>       }
>       return 0;
> }
>
>
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com