From: | James Mansion <james(at)mansionfamily(dot)plus(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Trevor Talbot <quension(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Win32 shared memory speed |
Date: | 2007-11-11 11:55:28 |
Message-ID: | 4736EDB0.90305@mansionfamily.plus.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander wrote:
> IIRC, there hasn't been any direct benchmark for it (though I've wanted to do that but had no time), but it's been the olnly real explanation put forward for the behaviour we've seen. And it does make sense given the thread-centric view of the windows mm.
>
> /Magnus
>
How is it supposed to be slow, once its mapped into your process?
There's no OS interaction at all then.
If you are suggesting that the inter-process synch objects are slow,
then that may be so: just use interlocked
increment and a spin lock in place of a mutex and use an associated
event to wake up if necessary.
You dont have to use a named kernel mutex, though it may be handy while
setting up the shared memory.
If you are repeatedly changing the mappings - well, that may be
something that needs optimisation.
James
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schiltknecht | 2007-11-11 13:11:50 | Re: High Availability, Load Balancing, and Replication Feature Matrix |
Previous Message | J=?ISO-8859-1?B?9g==?=rg Beyer | 2007-11-11 11:29:19 | Problem to configure pg8.3b2 w/ ossp-uuid-support on OS X |