apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: New Vista APIs
Date Sun, 14 Jan 2007 03:36:59 GMT
OK, let me rephrase what I previously meant to say:

Vista now provides kernel support some lightweight Reader/Writer Locks
that are just blocking-only. I haven't tested their performance (I
haven't got a Vista box) but they should be faster than the way APR is
working right now (there's only one system call for each apr function,
it does not eat up any system handle, the Slim RWLock object has the
size equal to sizeof(void*)).

Suppose developers A and B each want to build a portable application
(using APR) which by design uses RWLocks. They both want a small
footprint for their platform abstraction layer, but they also want to
use the best features any system has to solve the problem.

A's app only needs blocking RWLocks (and would like to have them
implemented as Slim RWLocks on the systems where they are supported:
Vista, Longhorn and what else may come).
B's uses both blocking and the apr_try functions (by which I mean
apr_thread_rwlock_tryrdlock and apr_thread_rwlock_trywrlock).

[Note: the names proposed here are just orientative, I was trying to
find an opinion on the kind of functionality desired, and also to be
corrected and shown a better solution if anyone thinks of a better way
to deal with this.]
I see two solutions on how to satisfy both users of the APR:
   S1. We add a now constructor for the apr_thread_rwlock_t object.
   S2. We add a new object type apr_thread_blockingrwlock_t

S1. We add a now constructor for the apr_thread_rwlock_t object.
   S1a.) apr_thread_rwlock_create_blockonly
          (apr_thread_rwlock_t **rwlock, apr_pool_t * pool)
   S1b.) a more extensible apr_thread_rwlock_create2
          (apr_thread_rwlock_t **rwlock, apr_pool_t * pool, apr_int32_t flag)
          and define two flags (just two for now, but others may be
added if we need
          to diversify implementations later) APR_THREAD_RWLOCK_BLOCKING_ONLY
          and APR_THREAD_RWLOCK_BLOCK_AND_NONBLOCK.
I chose the second one because it's open to extensions, but for what
we need here the first constructor will do just as well.
Whichever solution we choose, apr_thread_rwlock_t will need a new
apr_int32_t member which will tell weather the object is supposed to
support apr_try functions or not, and which will trigger an error if
apr_try functions are called on a APR_THREAD_RWLOCK_BLOCKING_ONLY
rwlcok. On all systems but Vista this is the only overhead: a new
member in the object and a check in the apr_try functions.

On Vista ALL functions check the value of this member and switch
between implementations. If APR_THREAD_RWLOCK_BLOCKING_ONLY is:
    i) set: all blocking apr functions use the Slim RWLocks system calls
                the apr_try functions return an error
    ii) not set: use the current win32 implementation.

S2. We add a new object type apr_thread_blockingrwlock_t
All apr_thread_blockingrwlock_ functions on all systems but Vista are
the same as the type apr_thread_rwlock_ ones. On Vista they call the
SRWLock equivalents.

Advantages:
S1: developer A discovers that he must use an apr_try function. He
renounces at the speed offered by SRWLocks to gain the functionality
of apr_try by
  a) using the apr_thread_rwlock_create constructor (we must keep the current
            constructor to keep current APR users happy)
  b) changing the flag passed to apr_thread_rwlock_create2
S2: an obvious separation of API capability: there are no apr_try functions to
         apr_thread_blockingrwlock_ objects.
     no need to change the apr_thread_rwlock_ & to have a flag checked in
         some functions.

Disadvantages:
S1: increase in the footprint of apr_thread_rwlock_t objects (the new flag)
      more overhead for some functions need to check a flag.
S2: changin between implementations is harder: one needs to replace
all functions
        and object definitions/declarations in his code.

And there's always S3: just ignore Slim RWLocks (but make developer A
a bit sad, as he'd like to use the lighter solution for his
implementation).



On 1/13/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> If you wanted to hack the existing thread_rwlock API when running with
> 1. a blocking socket 2. on Win Vista, it's something we would consider.

I think you meant to say:
1. a blocking reader/writer lock
2. on Win Vista

As I see it one can't just hack the implementation and satisfy both
developer A and B. When A creates rwlocks he wants them to be SRWLocks
for better performance and how these are the only kind he uses he'll
compile APR to use SRWLocks. But say he'll want to use both of them in
his code (a case of A=B). If we don't create a new API call we'll have
at least one disappointed developer.


Hope I made myself clearer now,
Lucian Adrian Grijincu

Mime
View raw message