Re: apr locks

On Wed, Dec 13, 2000 at 12:13:47PM -0600, Ben Collins-Sussman wrote:
>
> Greg S. --
>
> Do the routines in apr_lock.h work?

Absolutely. Apache would fall over mighty fast if they didn't :-)

> I have a global hash the contains all loaded RA-libraries. I want the
> structure global, so that multiple threads and processes can share the
> vtables.

Threads can share. Processes can't.

> However, I want to keep things threadsafe. When a thread
> needs to load a new RA library, I want to lock down the hash first.
>
> However, I have to admit, I've never used muteces. Looking at apr's
> interface, it looks like I need to
>
> * create a lock
> * associate data with it
> * lock the lock
> * edit the data
> * unlock the lock
>
> Is this right?

Create a global mutex (as a sibling of your hash). Initialize the mutex once
at startup (which will presumably be threadsafe at that point; maybe a
svn_client_init() function that users must call). Use the APR_INTRAPROCESS
lock scope to just lock threads out of the access to the hash.

The lock type (mutex vs readwrite) is apparently ignored. Forget that
parameter. fname appears to allow NULL, so the "always" in the comment is
bogus(*); you can pass NULL.

[ yes, it looks like I'll be going in there and revamping that API :-) ]

When anybody wants to read *or* write the hash, you must surround the access
with apr_lock() and apr_unlock().

Cheers,
-g

(*) Actually, only Unix allows a NULL parameter; all other platforms expect
    one. You should probably just pass one that resides in SVN/tmp/.

-- 
Greg Stein, http://www.lyra.org/