Andreas Pflug wrote:
> Bruce Momjian wrote:
>
>>
>>
>> Agreed. My pthread book says pthread_mutex_init() should be called only
>> once, and we have to guarantee that. If the Windows implentation allows
>> it to be called multiple times, just create a function to be called only
>> by Win32 that does that and leave the Unix safe.
>>
>>
>>
> Ok, so here's the win32 workaround with the unix stuff left untouched.
> There's no memory interlocking api in win32 that wouldn't need some
> initializing api call itself, so we'd have to go for assembly level
> test-and-set code.
Wrong. There are portable test-and-set functions in the Win32 SDK: for
example InterlockedCompareExchange. They operate on ints and do not need
initialization.
> or introduce a mandatory global libpq initializing api.
There is a third option: Add one C++ file and use the constructor to
initialize the mutex. VisualC is always a C++ compiler, thus C++ support
shouldn't be an issue. I've attached an example app.
> Considering the probably quite low usage of kerberos/ssl together with
> threads under win32, and the very low probability of two
> threads/processors (!) trying to initiate a connection at the same
> time, it doesn't seem to be worth the compiler hassle with assembly
> inline.
>
This argument is insane: Given enough installations, even a very low
probability will cause failures.
But this is a minor point, I think the patch should go in and I'll write
with a proposal to close the race, either based on
InterlockedCompareExchange or on a C++ file.
--
Manfred
#include <stdio.h>
#include <stdlib.h>
int g_mutex;
extern "C" int main(void) {
printf("in main. Value now %d.\n", g_mutex);
}
class init_me
{
public:
init_me::init_me(void)
{
g_mutex = 99; /* CreateMutex(), or whatever. */
}
};
static class init_me instance_one;