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 Sat, 13 Jan 2007 04:56:53 GMT
The Slim Reader/Writer (SRW) Locks implemented in Vista are blocking-only.
http://msdn2.microsoft.com/en-us/library/aa904937.aspx

Because of this, i don't think there's a way we can implement
apr_thread_rwlock_tryrdlock through SRWLocks.

A possible solution that I see means defining:

   - a new constructor function:
      - apr_thread_rwlock_create2 (apr_thread_rwlock_t **rwlock,
      apr_pool_t * pool, apr_int32_t flags )
   - a special APR_RWLOCK_FAST_BLOCKING flag.

A user that does not need the non blocking apr_...try functions will create
the rwlock by specifying this flag.
and apr_...try functions shall return some speciffic error.

If sometimes later he decides that he may want apr_thread_rwlock_tryrdlock
he can just remove the APR_RWLOCK_FAST_BLOCKING flag.

only on vista and laters, if SRW locks have been enabled(aka #define
APR_HAVE_SWR_LOCKS 1) this will have an overhead though:

   - apr_thread_rwlock_t will need a new member to hold this flag
   - every function call shall have to check if the flag is set or not,
   to switch between implementations.



Another solution would mean creating a special blocking
apr_thread_blrwlock_t structure and the same set of methods expect the two
apr_...try ones. This does not have the overhead of the former solution,
but, if a developer might discover during development time he *must* use one
of the apr_...try functions he'll have a bit more work: search and replace
"apr_thread_blrwlock*" with "apr_thread_rwlock*".

Oh yeah, and we can just drop this functionality altogether and keep the
current win32 on all platforms:)

Suggestions?



On 1/7/07, E Holyat <eholyat@yahoo.com> wrote:
>
> I took a class with the author of the Read/Writer API (Jeffrey
Richter).  It
> was written using the InterlockedExchange API.  It would be a huge
> improvement implementing the new API.
>

--
Best Regards,
Lucian Adrian Grijincu

Mime
View raw message