c++parallel-processingtransactionsintel-tsx

isLocked method for use in haswell RTM


I am currently developing an application using Intel Haswell RTM (Hardware support for transactional memory). From what I could see here and here, the recommended procedure is to use a fallback lock of some kind, in case the transaction aborts.

The recommended flow is the following:

someTypeOfLock fallback_lock;
if(_xbegin == _XBEGIN_STARTED) {
    if(fallback_lock.isLocked()) // put the lock into the transaction read_set
        _xabort();
    // do stuff
    _xend();
}
else{
    fallback_lock.acquire();
    // do stuff
    fallback_lock.release();
}

My question is with the isLocked() function. Until now I didn't find any mainstream library/class which provide this functionality (which, as seen here, is most of the time useless). Do you have any recommendations?

Thanks!


Solution

  • Andi Kleen suggested here using pthread_mutex_trylock (with some reservations).
    There's also a few slides mentioning using that for lock_is_locked() here. The first link claims that trylock would succeed in RTM thanks to special HW adaptation, i'm not entirely sure how this mechanism would work so i'm not sure I can recommend that.

    Instead, I think i'd personally choose a more direct approach of using any shared variable by setting it inside the fallback lock-guarded atomic section, and reading it instead of the try_lock. Something like this -

    someTypeOfLock fallback_lock;
    if(_xbegin == _XBEGIN_STARTED) {
        if(shared_var) // put the lock into the transaction read_set
            _xabort();
        // do stuff
        _xend();
    }
    else{
        fallback_lock.acquire();
        shared_var = true;
        // do stuff
        shared_var = false;
        fallback_lock.release();
    }
    

    The shared var serves as a poor-man lock, of course writing and reading to it is not protected by itself, but since it resides within the critical section it would provide the exact semantics you want (read only within RTM-attempted atomic section, write within fallback atomic section).

    Of course - it would be simpler if you could query the lock itself directly in a non intrusive way, but that depends on the lock library.