1

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!

Alex Guteniev
  • 12,039
  • 2
  • 34
  • 79
OlivierH
  • 385
  • 3
  • 12

2 Answers2

1

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.

Leeor
  • 19,260
  • 5
  • 56
  • 87
  • If I use pthread_mutex_trylock, and the lock is not yet locked, it seems I write to it, no? Thus aborting all parallel transactions? Also, could you expand on why just reading a shared variable is less efficient/safe? This seems the perfect solution, as I'm not interested in the value of this variable, but only in aborting the transaction in case of conflict? – OlivierH Dec 29 '13 at 15:45
  • @user3143937 - See my edit. I don't have any particular reason in mind against using a shared var, that's why I suggested it. In general i'd prefer using library functions over a manual hack, but you're right in that we shouldn't fully trust an unexplained method. – Leeor Dec 29 '13 at 16:41
0

What you want to do is to "read" the lock but without locking. To do this you need to carefully study the library of the lock you are using. Below you can see how to solve your problem for a mutex or a spinlock:

a)For spinlock: 

if ((int)spin_lock != 1) _xabort();

b)For mutex: 

if (pthread_mutex_t.__data.__lock != 0) _xabort ();
Gwenc37
  • 2,064
  • 7
  • 18
  • 22
George Mappouras
  • 1