Ok, call should be fine as well! In all cases, seems like writers are synchronized and any other usage is in the context of a protected section. CI also passes (though I haven't run it through SPARCv9+ and ARM, but we already have RMO and TSO coverage, nothing specific to ARM / SPARC with these changes).

This is actually good too! Sorry for the noise. It was an API violation to call poll on a record that is in a read section, but it seems there is no reason to have that API restriction to begin with at this point. The API restriction is removed now.

Let's merge from upstream if possible.

Merged upstream and passes tests. poll return value was changed a bit to only return false if no forward progress was made (no dispatch or no progression of epoch). It will return true if we're in a grace period or if anything has been dispatched.

Ok, all these changes here should be good. Thanks. Merging these upstream and then circling back on two issues we wanted to validate:

• Using writer function on active record (Matt has a simple work-around). As 12 is getting cut, we won't extend the API right now to allow for writer-functions to be used on active records.
• Usage of call.

Thanks for the update. I had a few items come up and will be unable to spend time on this until Saturday. I'll loop back here and I'll try my best to have things ready for Sunday. Unfortunately, Friday won't be realistic at the moment.

Ok. I caught up with Matt offline. This doesn't solve the problem at hand. The API is not being used as intended in some areas, so we will work to address that. I would advise against merging this in as it doesn't address the underlying issues:

Ok. I caught up with Matt offline. This doesn't solve the problem at hand. The API is not being used as intended in some areas, so we will work to address that. I would advise against merging this in as it doesn't address the underlying issues:

Is it possible to put these changes upstream first at https://github.com/concurrencykit/ck? We are responsive. You'll get more eye balls on the review and we have the advantage of CI with several torture tests for epoch on both TSO and RMO architectures. We are responsive. Longer term, if you're doing more work here, happy to provide commit privileges as well.

The above change should not have any impact if ck_epoch is being correctly used. For that reason, it's good to go. However, I am concerned about a larger problem.

In D17503#373529, @jtl wrote:

In D17503#373490, @sbahra_repnop.org wrote:

See previous note in D17492 regarding the assumption that write-side functions are *not* called with-in a read-side critical. Does FreeBSD require that this is permitted?

See my comments in that review.

Regardless of whether that is true, it seems like this change would still be safe. Do you agree?

See previous note in D17492 regarding the assumption that write-side functions are *not* called with-in a read-side critical. Does FreeBSD require that this is permitted? If so, there's a few other changes we may want to make and I'll need to do some additional validation.

Thanks much for this. Note that the assumption here is a writer thread *should not* be calling ck_epoch_synchronize or write while inside of a read-side critical section. In other words, the active bit must be set to 0. In this situation, the invariant is not violated. If inside a read-side critical section, bets are off. Is the assumption or requirement here that it be safe to call synchronize from with-in a read-side critical section? If so, there are a few other areas we could fix up.

On x86* and other TSO architectures, note that the fences will be emitted. With respect to code movement, the loads will be not be elided in eitherway. I doubt there would be measurable overhead.

@avg Does FreeBSD plan to support Alpha? I honestly wouldn't bother with memory_order_consume unless the FreeBSD model mandates it. All modern architectures are sane with respect to data-dependent loads. Plus, there is a lot more code that would actually need to be using it, that doesn't.

ck_ring has slightly different semantics (it is completely lock-free on consumer, but assumes UINT_MAX operations don't occur during a delay in dequeue) but I took a stab at the buf_ring MP semantics today. I have tested this on RMO architectures and verified the fences with fault injection.