RE: (ITS#4662) ldap_create needs lock?

[volz@cisco.com]

>Of course, you could avoid the problem by simply calling an appropriate

>libldap function in the main process, before spawning any child
threads.
 
That is how I fixed it in our software for now. But it was an annoying
issue to chase down as the documentation never warns about it and I had
to analyze the OpenLDAP source to do it. I'm just trying to save others
the aggrevation.


In Windows, you can create a named mutex (see CreateMutex):

"Two or more processes can call CreateMutex to create the same named
mutex. The first process actually creates the mutex, and subsequent
processes with sufficient access rights simply open a handle to the
existing mutex. This enables multiple processes to get handles of the
same mutex, while relieving the user of the responsibility of ensuring
that the creating process is started first. When using this technique,
you should set the bInitialOwner flag to FALSE; otherwise, it can be
difficult to be certain which process has initial ownership."

There's no reason why multiple threads can't be doing this instead of
multiple processes.

Of course, the name used must be unique to allow multiple processes to
run -- so using the PID of the process might be a good thing to include
in the name.

Note also:

"Use the CloseHandle function to close the handle. The system closes the
handle automatically when the process terminates. The mutex object is
destroyed when its last handle has been closed."

So, there's no explicit need to do cleanup!

- Bernie

-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com] 
Sent: Monday, September 11, 2006 10:24 PM
To: Bernie Volz (volz)
Cc: openldap-its@OpenLDAP.org
Subject: Re: (ITS#4662) ldap_create needs lock?

Bernie Volz (volz) wrote:
> What about registering an initialization entry point when the library
is
> loaded? Though that only solves the problem when the .so/.dll is used;
> not when someone links directly with the object module.
> 
> Though I do find it difficult to believe static initialization isn't
> possible?
> 
> Windows has it.

Hm, last I checked, Windows does not have it. Most people seem to solve 
this by using a constructor. (I.e., a small init function that runs at 
DLL load time.)

Of course, you could avoid the problem by simply calling an appropriate 
libldap function in the main process, before spawning any child threads.
> 
> Linux and Solaris have it (see
> http://www.die.net/doc/linux/man/man3/pthread_mutex_init.3.html).
> 
> Sure, you'd need a #define or something similar that works on all
> platforms, but that shouldn't be that difficult? I've done so for
> Windows, Solaris, and Linux.
> 
> - Bernie 

>> In ldap_create, if multiple threads are calling ldap_init (or one of
> the other
>> initialization functions), they may compete to initialize the global
> options and
>> this results in a segmentation fault.
> 
>> Shouldn't the above code be conditionalized on LDAP_R_COMPILE and use
> a static
>> global mutex to assure that only one thread is testing and
potentially
>> initializing the global options.
> 
> Unfortunately static mutex initializers are non-portable. I guess for 
> gcc we could arrange to have a constructor do the initialization, but 
> it's not clear what we can do for the more general case.
> 


-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/