Esistono equivalenti al futex in Linux/Unix?

Question

Sto cercando qualcosa potrebbe essere utilizzato per polling (come select, kqueue, epoll cioè non occupato polling) in C/C++. In altre parole, ho bisogno di bloccare un thread e quindi di riattivarlo in un altro thread con il più piccolo overhead possibile.

A mutex + condition variable funziona, ma c'è un sacco di spese generali. Anche un futex funziona, ma è solo per Linux (o forse no?). La sincronizzazione aggiuntiva non è necessaria finché il polling funziona correttamente, ad es. nessuna gara quando chiamo wait e wake in due thread.

Modifica: Se tale "funzione" non esiste in FreeBSD, come crearne una con tipi e chiamate di sistema incorporati in C++ 11?

Edit2: Dal momento che questa domanda è migrato a SO, mi piacerebbe per renderlo più generale (non per FreeBSD solo)

Answer 1

Volete semafori e non mutex per la segnalazione tra l'una discussioni ..

http://man7.org/linux/man-pages/man3/sem_wait.3.html

semafori può essere utilizzato come un banco come se si dispone di una coda, si incrementerà (post) al semaforo ogni volta che si inserisce un messaggio, e il vostro decremento del ricevitore (attesa) sul semaforo per ogni messaggio tira fuori. Se il contatore raggiunge lo zero, il ricevitore bloccherà fino a quando non verrà pubblicato qualcosa.

Quindi uno schema tipico è quello di combinare un mutex e un semaforo come;

sender: 
    mutex.lock 
    insert message in shared queue 
    mutex.unlock 
    semaphore.post 

receiver: 
    semaphore.wait 
    mutex.lock 
    dequeue message from shared structure 
    mutex.unlock 

Answer 2

semafori non sono mutex, e funzionerebbero con leggermente meno overhead (evitando il mutex + condvar ri-lock, per esempio)

notare che, poichè qualsiasi soluzione in cui un filo ospitare fino risvegliato comporterà un kernel syscall, non è ancora economico. Supponendo x86_64 glibc e le libc FreeBSD sono entrambe le implementazioni ragionevoli, il costo inevitabile sembra essere:

sincronizzazione

1. modalità utente del conteggio (con un CAS o simile) gestione
2. kernel della coda di attesa e filo sonno/attendere

Suppongo che il mutex + spese generali condvar siete preoccupati è la sequenza cond_wait-> ri-Lock> sbloccare, che è infatti evitato qui.