On Wed, Mar 28, 2012 at 3:25 AM, Daniel Herring wrote:
> The exact same issue occurs with condition variables. As a result, the
> caller of pthread_cond_signal frequently needs to use the same mutex as the
> caller of pthread_cond_wait.
>
Yes, I know, but condition variables are really not a goo
On Tue, 27 Mar 2012 21:25:38 -0400 (EDT)
Daniel Herring wrote:
Hopefully Juan Jose can clarify if I'm wrong in the following answers,
as I'm not aware of all issues involved with locking and interrupts in
ECL.
> Can't you use pthread_mutex_trylock to query whether a thread is locked?
> Not supe
On Tue, 27 Mar 2012, Juan Jose Garcia-Ripoll wrote:
> This is tricky. Ideally we should not need any polling at all. The only
> reason for polling to exist is because we do not have a portable
> implementation of a wait queue, such as C++'s new eventcount. In other words,
> we the slow path
> l
On Tue, Mar 27, 2012 at 2:41 PM, Daniel Herring wrote:
> Here are some thoughts to make a fair lock fast: Quickly detect and take
> the fast path (atomics to bypass all locking).
>
This is already throughout ECL's code. Atomics have been incorporated via
libatomics and their intelligent headers
On Sun, 25 Mar 2012, Juan Jose Garcia-Ripoll wrote:
> Working further on the userspace implementation locks, I realized that it is
> hard to come up with an implementation that is both fast and fair,
> understanding by the last concept the fact that all threads have more or less
> the same
> ch
Working further on the userspace implementation locks, I realized that it
is hard to come up with an implementation that is both fast and fair,
understanding by the last concept the fact that all threads have more or
less the same chances to acquire a lock. POSIX threads seem to acomplish
this nice
