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 <[EMAIL PROTECTED]> 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
