svn commit: r195918 - head/sys/netinet

[Robert Watson]

On Wed, 29 Jul 2009, Randall Stewart wrote:

>> Instead of using additional argument to the sctp_add_to_readq() function, 
>> wouldn't it be sufficient to just check with mtx_owned(9) if the lock is 
>> already held?
>
> Hmm... I suppose one could go that way... but traditionally upper code as 
> told the lower code that it holds/does not hold the lock. This is true in 
> quite a few other functions...

Structures of the form:

 	if (mtx_owned(&mtx))
 		mtx_unlock(&mtx);

Strike me as less robust than code with either fixed assertions about lock 
state from the caller, or code that accepts a flag that in effect leads to two 
variants each with fixed state that can be asserted.  I.e.,

 	void
 	foo(void *obj)
 	{

 		OBJ_LOCK_ASSERT(obj);
 		...
 	}

or:

 	void
 	foo(void *obj, int arg_locked)
 	{

 		if (arg_locked)
 			OBJ_LOCK_ASSERT(obj);
 		else
 			OBJ_LOCK(obj);
 		...
 		if (!arg_locked)
 			OBJ_UNLOCK(obj);
 	}

I guess I'm sort of OK with structure but it smacks of poor code design:

 	void
 	foo(void *obj)
 	{
 		int locked;

 		if (OBJ_LOCK_OWNED(obj)) {
 			locked = 1;
 			OBJ_LOCK(obj);
 		} else
 			locked = 0;
 		...
 		if (locked)
 			OBJ_UNLOCK(obj);
 	}

However, this structure doesn't lend itself to moving to lock types that can't 
cheaply support mtx_owned()-like operations, such as read acquisitions of 
reader-writer locks.

Robert N M Watson
Computer Laboratory
University of Cambridge