apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: apr_memory_system.c;apr_memory_system.h
Date Tue, 08 May 2001 18:02:57 GMT
> sander, it occurs to me that this may actually have to
> be exposed up to the users of a memory block, in some
> way, for exactly the same reasons that tdb has tdb_lock()
> and tdb_unlock().
> you wish to perform some transaction on the memory, but
> it is up to the implementor of the apr_memsys to hide the
> details of the locking required from the users of that
> apr_memsys.
> i don't just mean for accounting / management, i mean
> for actual usage.
> we cannot assume that some locking (blocking signals)
> which would be suitable for system-memory when accessed
> by threads would be suitable when another apr_memsys
> is used, by the same code.
> so, we really do need to provide apr_memsys_lock()
> and unlock.

Right, ok, this I buy ;-)
[background: Luke and I have been talking about this a
 few times and there never was a conclusive reason to
 include apr_memory_system_lock() and
 apr_memory_system_unlock(). With these comments, I think
 we have a case where indeed these _are_ needed]

> i would recommend that it take three arguments, like so:
> apr_memsys_lock(apr_memsys_t, void *mem, size_t start, size_t end);
> with a comment saying that if the void *mem is NULL,
> this means 'perform a global, or "management"-suitable, lock'.
> yuck, but there y'go.

Hmmm, I think the exposed apr_mem_sys_lock/unlock functions
should be done for memory usage/access only. In other words,
the user will have to call these, the framework _never_ will,
not even in management functions (ie. malloc, realloc, free,
reset, etc).

Usage example:

  apr_memory_system_t *shms;
  void *mem;

    standard_memory_system_somewhere, "somekey"); /* don't get the key part
                                                   * yet, but I guess you
                                                   * are going to explain it
                                                   * to me :^) */

  /* the implementation of the shared memory system will do locking
   * stuff internally (hidden from the user) */
  mem = apr_memory_system_malloc(shms, 512);

  /* when using the memory the user has to lock it explicitly (as always) */
  apr_memory_system_lock(shms, mem, 0, 512); /* Do we really need the range?
  [.. do something with the memory ..]
  apr_memory_system_unlock(shms, mem, 0);


There are probably syntactic issues here, so could someone please state how
they would like the locking/unlocking to look like.

> also, implementors of an apr_memsys may optionally ignore the
> mem, start and end arguments, and simply implement apr_memsys_lock()
> as a global lock.
> .... would that cause problems?  because if it might,
> it's best to say _now_ :)  e.g. perform two locks on two
> separate locations, expecting them to both work, and
> you have deadlock - even in a single process.

Hmmm, that's not very nice, is it? Can we think of smart locking code
that will take care of this?

> apr_memsys_lock_region(...)
> apr_memsys_lock_global(.)
> with optional support for lock_region().
> luke


View raw message