On May 14, 2009, at 7:41 PM, Chris Darroch wrote:
Jim Jagielski wrote:
On May 14, 2009, at 3:36 AM, jean-frederic clere wrote:
Yeah... when a do is done, we want to ensure that
none of the slots change since we are touching all slots.
In general, we assume that with get and put, only one thread is
touch any particular slot at one time.
What about multiple processes performing a put() on the same
slot? It sounds like the current use case tends to be strictly
intra-process, but the API doesn't require that, I believe.
This is why I'd either pull all the locking out and let
the user decide (none, intra-process [thread mutexes] only,
inter-process [global mutexes], or some custom thing). The
provider just doesn't know enough to be certain and we end up
doing expensive global locking, or having to provide a Swiss
army knife set of locking options and them implementing them
all in each provider (slotmem and socache). But that's just
my two cents.
No, I agree it's a compelling argument... How about this as a
compromise: The create/init accepts 2 additional arguments,
a locking function pointer and an unlock function pointer.
So the end user needs to determine what sort of locking they
want when using the slotmem. The slotmem then mutexes all
access to the slots with this mutex. Additionally, each
slotmem function also accepts a flag that says "use provided
locking or force no-locking", so that even if a mutex is provided,
the end-user can decide "No, I know this is safe and so I want
to do this without any locking" for an optimization.
I think what I'm trying to avoid code that always has
LOCK_SLOT();
slotmem_put(.....);
UNLOCK_SLOTOP;
All over the place...
