Can you please explain the use case for this API? We already have odp_schedule_order_unlock and odp_schedule_order_lock. These APIs can be used to do the same operation.
On 16 June 2017 at 09:12, Bill Fischofer <[email protected]> wrote: > On Fri, Jun 16, 2017 at 6:21 AM, Balasubramanian Manoharan > <[email protected]> wrote: >> Adds api to release an existing ordered lock and acquire a new lock. >> >> Signed-off-by: Balasubramanian Manoharan <[email protected]> >> --- >> include/odp/api/spec/schedule.h | 20 ++++++++++++++++++++ >> 1 file changed, 20 insertions(+) >> >> diff --git a/include/odp/api/spec/schedule.h >> b/include/odp/api/spec/schedule.h >> index 8244746..c5d2214 100644 >> --- a/include/odp/api/spec/schedule.h >> +++ b/include/odp/api/spec/schedule.h >> @@ -368,6 +368,26 @@ void odp_schedule_order_lock(unsigned lock_index); >> void odp_schedule_order_unlock(unsigned lock_index); >> >> /** >> + * Release ordered context lock and acquires new lock >> + * >> + * This call is valid only when holding an ordered synchronization context. >> + * Release a previously locked ordered context lock and acquires > > Grammar: acquire > >> + * a new ordered context lock. >> + * This call is valid only when there is a single ordered context lock and >> + * is invalid if there are nested ordered context lock. > > Need to clarify what this means. I'm assuming the restriction is that > the caller may only hold a single ordered lock at the time of the > call? > >> + * >> + * @param lock_index Index of the ordered lock in the current context to >> be >> + * acquired. Previously acquired ordered lock is >> released. >> + * Results are undefined if there is a nested ordered >> lock > > if the caller does not hold exactly one ordered lock? > >> + * in the context. Must be in the range >> + * 0...odp_queue_lock_count() - 1 >> + * >> + * @see odp_schedule_order_lock(), odp_schedule_order_unlock() >> + * >> + */ >> +void odp_schedule_order_unlock_lock(uint32_t lock_index); > > Since odp_schedule_order_unlock() currently takes a lock index, it > would be consistent (and eliminate a lot of the above confusion) if > this were specified as: > > void odp_schedule_order_unlock_lock(uint32_t old_lock_index, uint32_t > new_lock_index); > > That makes it clear which lock is being unlocked and which is being > locked and means that it doesn't matter if one or more other locks are > held at the time of this call. > >> + >> +/** >> * @} >> */ >> >> -- >> 1.7.9.5 >>
