Re: [Tipc-discussion] New file release tipc-1.3.10

[Jon M. <jon...@er...>]

I realize the problem, but I have difficulties with seeing 
how we can do otherwise if we want lock granularity 
per node instance. 
I tried to make it clear via the function names, but it can certainly 
be improved by better comments on this. (I already have such 
comments at some places.)  
I think improved comments is the best we can do, unless somebody 
has a  better idea.

Regards /Jon

Daniel McNeil wrote:


On Thu, 2004-04-29 at 08:15, Jon Maloy wrote:

  

Do you suggest that we delay the LKML-announcement until we have done

these changes ? To replace all the linked lists is intrusive, and it

may 

take weeks re-stabilize the code. Otherwise, see my comments below.



Regards /jon



    



Jon,



One other thing about TIPC that Mark and I have noticed that might

cause mainline acceptance problems is the:



	ref_lock_acquire(void *object,spinlock_t ** lock)

	ref_lock_deref()



	namesub_lock_deref()

	ref_unlock_discard(s->publ.s.ref);





	port_lock_deref()

	spin_unlock_bh(this->publ.lock);

	ref_unlock_discard(ref);







2 big concerns:



1. This hides the locking since a pointer is set to the "real" lock.

   The usage above just does not seem clear on what is being locked.

  

2. The lock is locked in one function and returned with the spinlock

   held and then unlock() in a different function.



Maybe more comments on functions saying which locks are assumed held

and which locks are unlocked that came in locked might clear up some

of the confusion.



Thanks,



Daniel