Re: [HACKERS] [PATCHES] Compiling libpq with VisualC
What is the recommended way to create mutex objects (CreateMutex) from Win32 libraries? There must be a clean way like there is in pthreads. A mutex is inherently a global object. CreateMutex(NULL, FALSE, NULL) will return a handle to an unowned mutex. That's not the problem. Under pthread, it's possible to initialize a mutex from compile time: static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER; This means that the mutex is immediately valid, no races with the initialization. I couldn't find an equivalent Win32 feature. AFAIK, there is no such thing on Win32. The clean way is probably to rqeuire the library to export a function InitialyzeFooLibrary() that does it (like Winsock does with requiring WSAStartup()). To do something like it though, you can use a named mutex. Then doing, in pseudocode: if (CreateMutex(...,my_unique_mutex_name) == ERROR_ALREADY_EXISTS) OpenMutex(...,my_unique_mutex_name) Assuming nobody closes the mutex between your attempt to create and open (which shouldn't happen if you just ignore closing it until process exit), this should be safe. Store the HANDLE to the Mutex in TLS, and have each thread do the create/open when it needs the mutex (e.g. wrap the wait on the mutex in a function/macro that will create/open the mutex if it's INVALID_HANDLE_VALUE, which you assign it to by default). You need a unique name for the mutex, since it's not per-process but per-sessino. But that can easily be constructed from the pid. //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Compiling libpq with VisualC
[ Thread moved to hackers and win32.]
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 or introduce a mandatory global libpq initializing
api. 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.
What is the recommended way to create mutex objects (CreateMutex) from
Win32 libraries? There must be a clean way like there is in pthreads.
A mutex is inherently a global object. CreateMutex(NULL, FALSE, NULL) will
return a handle to an unowned mutex.
---
In the patch Win32, pthread_mutex_init() == CreateMutex():
+#ifndef WIN32
static pthread_mutex_t singlethread_lock =
PTHREAD_MUTEX_INITIALIZER;
+#else
+ static pthread_mutex_t singlethread_lock;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+{
+mutex_initialized = 1;
+pthread_mutex_init(singlethread_lock, NULL);
+}
+#endif
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania
19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] Compiling libpq with VisualC
[EMAIL PROTECTED] wrote: [ Thread moved to hackers and win32.] 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 or introduce a mandatory global libpq initializing api. 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. What is the recommended way to create mutex objects (CreateMutex) from Win32 libraries? There must be a clean way like there is in pthreads. A mutex is inherently a global object. CreateMutex(NULL, FALSE, NULL) will return a handle to an unowned mutex. Yes, but consider that two threads could both call it, with one perhaps using the first value, and the second overwriting the first. Obviously not something we want. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Compiling libpq with VisualC
[EMAIL PROTECTED] wrote: What is the recommended way to create mutex objects (CreateMutex) from Win32 libraries? There must be a clean way like there is in pthreads. A mutex is inherently a global object. CreateMutex(NULL, FALSE, NULL) will return a handle to an unowned mutex. That's not the problem. Under pthread, it's possible to initialize a mutex from compile time: static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER; This means that the mutex is immediately valid, no races with the initialization. I couldn't find an equivalent Win32 feature. -- Manfred ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Compiling libpq with VisualC
[ Thread moved to hackers and win32.]
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 or introduce a mandatory global libpq initializing
api. 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.
What is the recommended way to create mutex objects (CreateMutex) from
Win32 libraries? There must be a clean way like there is in pthreads.
---
In the patch Win32, pthread_mutex_init() == CreateMutex():
+#ifndef WIN32
static pthread_mutex_t singlethread_lock = PTHREAD_MUTEX_INITIALIZER;
+#else
+ static pthread_mutex_t singlethread_lock;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+{
+mutex_initialized = 1;
+pthread_mutex_init(singlethread_lock, NULL);
+}
+#endif
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
