You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Lucian Adrian Grijincu <lu...@gmail.com> on 2007/01/06 16:23:18 UTC
New Vista APIs
Vista come with a set of new APIs
http://msdn2.microsoft.com/en-us/library/aa904937.aspx
"Slim reader/writer (SRW) locks enable the threads of a single process
to access shared resources; they are optimized for speed and occupy
very little memory."
the interface is very similar to the one APR has in
http://apr.apache.org/docs/apr/trunk/group__apr__thread__rwlock.html
implementing apr_thread_rwlock through these APIs would be very
simple: we almost only have to call the corresponding OS functions.
the same stands for Condition variables:
http://msdn2.microsoft.com/en-us/library/ms682052.aspx
"Condition variables are synchronization primitives that enable
threads to wait until a particular condition occurs. Condition
variables are user-mode objects that cannot be shared across
processes."
I haven't looked any further into the matter (performance of the new
APIs relative to APR's current implementation, or if there are any
other new Vista APIs that may simplify the APR's implementation of x
and y functions), but I wanted to get your opinion on this: is there
any desire to have (with a compile time switch) APR's functions
implemented through the new set op API's ?
--
Best Regards,
Lucian Adrian Grijincu
Re: New Vista APIs
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Garrett Rooney wrote:
> On 1/13/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
>>
>> anyways, my former question stands: how would you like apr to deal
>> with this issue: have a secondary constructor, or have a new set of
>> objects (or just forget about it)?
>
> In general, it seems like if we can't provide a cross-platform API
> with this new low level interface, I don't see the point in using it
> at all... If it's absolutely going to require new interfaces with
> special cases to make it work, then I'm not sure what the real benefit
> would be. I mean this is a "Portable Runtime", after all.
Agreed.
If it doesn't represent a portable construction, don't pollute apr with
it, but deploy it in your applications when you desire.
If you have to do an #if PLATFORM to use an apr feature, it's broken
and shouldn't have been an apr feature.
Re: New Vista APIs
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Lucian Adrian Grijincu wrote:
>> Maybe a create flag APR_TRYLOCK_MAY_BLOCK?
>>
> I was thinking more in the realm of APR_TRYLOCK_WILL_FAIL:
> a.) WILL because we'd want a similar behavior on all platforms
> (portability, no?). If we use this API
> on Vista we'll either block or return an error (APR_EINVAL ...
> invalid apr_thread_rwlock_t
> used with the _trylock function). The code must behave the same
> on unices and the rest.
> b.) FAIL because blocking:
> 1) is harder to implement than a return error :)
> 2) violates the contract of the _trylock function
No, because we won't GUARANTEE it to fail, because we would refuse to add
processing cycles to determine if the flag was used where it is unneeded
and offers no performance boost. We also have no desire to fail the
call to create, either. Let it proceed...
This is an optimization that allows rwlock to choose a mechanism that
offers no trylock, but still allows it to use a mechanism that would
support trylock. The difference is, the platform uses the most efficient
method, and adds cpu cycles for the logic, only if it pays off as a WIN
on that platform.
Optimizations aren't supposed to penalize other platforms.
Re: New Vista APIs
Posted by Lucian Adrian Grijincu <lu...@avira.com>.
William A. Rowe, Jr. wrote:
> Lucian Adrian Grijincu wrote:
>
>> Let's suppose that we have apr_thread_rwlock_create2
>> (apr_thread_rwlock_t **rwlock,
>>
>> apr_int32_t flag,
>>
>> apr_pool_t *pool).
>>
>> and we define two flags to create separate types of objects:
>> apr_thread_rwlock_t which can and which cannot be used in trylock calls.
>> the performance of the ones which cannot be used in tyolock calls will
>> be the same on all platforms except for Vista, where we should see some
>> sort of improvement.
>>
>
> We have this elsewhere in our locking API. It seems like an awkward
> construct if we use an APR_BLOCKING flag, since it wouldn't be obvious
> to the casual programmer that it means "we won't _trylock".
>
> Maybe a create flag APR_TRYLOCK_MAY_BLOCK?
>
I was thinking more in the realm of APR_TRYLOCK_WILL_FAIL:
a.) WILL because we'd want a similar behavior on all platforms
(portability, no?). If we use this API
on Vista we'll either block or return an error (APR_EINVAL ...
invalid apr_thread_rwlock_t
used with the _trylock function). The code must behave the same
on unices and the rest.
b.) FAIL because blocking:
1) is harder to implement than a return error :)
2) violates the contract of the _trylock function
--
Lucian Adrian Grijincu
Re: New Vista APIs
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Lucian Adrian Grijincu wrote:
>
> Let's suppose that we have apr_thread_rwlock_create2
> (apr_thread_rwlock_t **rwlock,
>
> apr_int32_t flag,
>
> apr_pool_t *pool).
>
> and we define two flags to create separate types of objects:
> apr_thread_rwlock_t which can and which cannot be used in trylock calls.
> the performance of the ones which cannot be used in tyolock calls will
> be the same on all platforms except for Vista, where we should see some
> sort of improvement.
We have this elsewhere in our locking API. It seems like an awkward
construct if we use an APR_BLOCKING flag, since it wouldn't be obvious
to the casual programmer that it means "we won't _trylock".
Maybe a create flag APR_TRYLOCK_MAY_BLOCK?
Re: New Vista APIs
Posted by Lucian Adrian Grijincu <lu...@avira.com>.
My main point for now is that the current API was not designed with
extensibility in mind (but given the fact that all implementations
(except for Vista's new one) provide a means to do "trylock" without any
performance loss to just lock() and release(), no one's to blame. There
was no need for such a new parameter).
Just adding a flag parameter to the apr_thread_rwlock_create and
apr_thread_cond_create constuctors would have been better than the
current situation.
Let's suppose that we have apr_thread_rwlock_create2
(apr_thread_rwlock_t **rwlock,
apr_int32_t flag,
apr_pool_t *pool).
and we define two flags to create separate types of objects:
apr_thread_rwlock_t which can and which cannot be used in trylock calls.
the performance of the ones which cannot be used in tyolock calls will
be the same on all platforms except for Vista, where we should see some
sort of improvement.
Garrett Rooney wrote:
> In general, it seems like if we can't provide a cross-platform API
yes we can, we build it upon the current implementation (to which it
will default on platforms that don't have a better performance on
blocking only rwlocks [this currently means only Vista, but who knows
what time may bring] ).
furthermore, this may be implemented without breaking the API: we just
add new constructors. the old ones keep their functionality, nothing breaks.
It's cross-platform and on top it provides the users the possibility to
use a somewhat lighter implementation if they don't require all the
features of a full apr_thread_rwlock_t ( if you only need to power up an
MP3 player why build a personal thermonuclear power plant? Ok, I know
I'm exagerating, and talking without knowing exactly how much
improvement this new API brings, although 'till I get Vista I'll base my
claims on what I read on several sites.).
The thing I don't really get is why the reticence?
Yes, adding a new constructor is kind of ugly ... I don't really like it
myself ... but this is only due to the fact that the original
constructor cannot cope with todays reality.
> with this new low level interface, I don't see the point in using it
> at all... If it's absolutely going to require new interfaces with
> special cases to make it work, then I'm not sure what the real benefit
as I said, there's only a new constructor to be added. There are no
special cases. The new constructor will make two kinds of objects
blocking and nonblocking. That's it.
Furthermore apr_thread_mutex_t is designed from the start to do the
exact same thing I'm describing here.
It has a flag field. If you want this specific feature set the flag to
some value and we'll use a less performant implementation (Events), but
which gives us the possibility to provide the requested feature.
If you don't need that feature, we'll use this super fast lightweight
solution (CriticalSections). But beware: stuff may break if you use a
CriticalSections-based implementation in improper manners :).
> would be. I mean this is a "Portable Runtime", after all.
>
> -garrett
--
Lucian Adrian Grijincu
Re: New Vista APIs
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/13/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> the two cond_wait functions in APR:
> apr_thread_cond_wait(apr_thread_cond_t *cond, apr_thread_mutex_t *mutex) and
> apr_thread_cond_timedwait (apr_thread_cond_t *cond, apr_thread_mutex_t
> *mutex, apr_interval_time_t timeout)
>
> use a apr_thread_mutex_t as the object being unlocked.
>
> the new condition variable form Vista unlocks either a CriticalSection
> or a SRWLock object (SleepConditionVariableCS and
> SleepConditionVariableSRW)
>
> the win32 implementation for apr_thread_mutex_t on Vista uses either
> Events or CriticalSections depending on weather
> APR_THREAD_MUTEX_UNNESTED was specified when the lock was constructed
> or not.
>
> We can't just use the new calls on Vista because we can't atomically
> "release" an event and sleep on the condition variable.
>
> Because of this we'll need a new constructor
> apr_thread_cond_create2 (apr_thread_cond_t **cond,
> apr_int32_t * flag,
> apr_pool_t * pool)
>
> and have the developer specify which kind of lock he's going to use
> with this lock.
> If he chooses to use APR_THREAD_MUTEX_UNNESTED locks, we'll revert to
> the current implementation. If he guarantees he won't use these kind
> of locks we can freely use the new Condition variables.
>
> anyways, my former question stands: how would you like apr to deal
> with this issue: have a secondary constructor, or have a new set of
> objects (or just forget about it)?
In general, it seems like if we can't provide a cross-platform API
with this new low level interface, I don't see the point in using it
at all... If it's absolutely going to require new interfaces with
special cases to make it work, then I'm not sure what the real benefit
would be. I mean this is a "Portable Runtime", after all.
-garrett
Re: New Vista APIs
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
the two cond_wait functions in APR:
apr_thread_cond_wait(apr_thread_cond_t *cond, apr_thread_mutex_t *mutex) and
apr_thread_cond_timedwait (apr_thread_cond_t *cond, apr_thread_mutex_t
*mutex, apr_interval_time_t timeout)
use a apr_thread_mutex_t as the object being unlocked.
the new condition variable form Vista unlocks either a CriticalSection
or a SRWLock object (SleepConditionVariableCS and
SleepConditionVariableSRW)
the win32 implementation for apr_thread_mutex_t on Vista uses either
Events or CriticalSections depending on weather
APR_THREAD_MUTEX_UNNESTED was specified when the lock was constructed
or not.
We can't just use the new calls on Vista because we can't atomically
"release" an event and sleep on the condition variable.
Because of this we'll need a new constructor
apr_thread_cond_create2 (apr_thread_cond_t **cond,
apr_int32_t * flag,
apr_pool_t * pool)
and have the developer specify which kind of lock he's going to use
with this lock.
If he chooses to use APR_THREAD_MUTEX_UNNESTED locks, we'll revert to
the current implementation. If he guarantees he won't use these kind
of locks we can freely use the new Condition variables.
anyways, my former question stands: how would you like apr to deal
with this issue: have a secondary constructor, or have a new set of
objects (or just forget about it)?
PS: on vista systems we can also modify apr_thread_lock_t to use
SRWLocks in exclusive mode instead of CriticalSections.
some coverage about the new synchronization APIs from Vista here:
http://www.bluebytesoftware.com/blog/PermaLink,guid,db9f8f5b-8d1d-44b0-afbd-3eadde24b678.aspx
On 1/6/07, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 1/6/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
>
> Considering the number of complaints that people have had with our
> condition variable implementation on win32 over the years, I think an
> implementation in terms of a native win32 condition variable API would
> probably be a good thing, even if it's vista-only and won't be
> practically usable for many people for quite some time.
>
> -garrett
>
--
Lucian Adrian Grijincu