2010-06-18 9 views
20

Recentemente ho riscontrato la necessità di dormire il thread corrente per un periodo di tempo esatto. Conosco due metodi per farlo su una piattaforma POSIX: usando nanosleep() o usando boost::this_thread::sleep().boost :: this_thread :: sleep() vs. nanosleep()?

Per curiosità più di ogni altra cosa, mi chiedevo quali fossero le differenze tra i due approcci. C'è qualche differenza di precisione, e c'è qualche ragione per il non per usare l'approccio Boost?

nanosleep() approccio:

#include <time.h> 
... 
struct timespec sleepTime; 
struct timespec returnTime; 
sleepTime.tv_sec = 0; 
sleepTime.tv_nsec = 1000; 
nanosleep(&sleepTime, &returnTime); 

approccio Boost:

#include <boost/date_time/posix_time/posix_time.hpp> 
#include <boost/thread/thread.hpp> 
... 
boost::this_thread::sleep(boost::posix_time::nanoseconds(1000)); 
+3

Solo una piccola nota all'esempio: 'nanosecondi' non è disponibile su tutti i sistemi. L'uso di 'microsecondi' sarebbe più sicuro. – real4x

risposta

26

Le poche ragioni per le quali l'uso spinta che mi viene in mente:

  • boost::this_thread::sleep() è un punto interruzione boost.thread
  • boost::this_thread::sleep() può essere drop-in sostituito da C++ 0x di std::this_thread::sleep_until() in future

Perché no, se non stai utilizzando thread o di tutto il resto in te r progetto utilizza le chiamate POSIX, quindi nanosleep() ha più senso.

Per quanto riguarda la precisione, sul mio sistema sia boost che nanosleep() chiamano la stessa chiamata di sistema, hrtimer_nanosleep(). Immagino che gli autori di boost cerchino di ottenere la massima precisione possibile su ciascun sistema e per me è la stessa cosa che fornisce lo nanosleep().

+6

+1 - si dovrebbe notare che la tempistica basata sui thread sleeps, anche a livello di nanosleep, non è affidabile al massimo. –

+0

Un motivo per usare 'this_thread :: sleep()' è perché richiede tempo in qualsiasi unità tu voglia: 'sleep (seconds (10))', 'sleep (nanosecondi (10))', 'sleep (attoseconds (10)) '. La risoluzione hardware non cambia, ma qualsiasi risoluzione offerta può essere esposta senza necessità di continuare a introdurre nuove API di sleep ('sleep',' usleep', 'nanosleep', ecc.). – bames53

4

v'è alcuna ragione per non utilizzare l'approccio Boost

Suppongo che questo è una specie di ovvio, ma l'unica ragione per cui posso pensare è che avresti bisogno di aumentare t o compilare il tuo progetto.

+0

Suppongo che avrei dovuto dire che il progetto utilizza già altre librerie di boost. Tuttavia, una risposta valida alla domanda generale. –

5

Che ne dici perché il tuo esempio nanonsleep è sbagliato.

#include <time.h> 
... 
struct timespec sleepTime; 
struct timespec time_left_to_sleep; 
sleepTime.tv_sec = 0; 
sleepTime.tv_nsec = 1000; 
while((sleepTime.tv_sec + sleepTime.tv_nsec) > 0) 
{ 
    nanosleep(&sleepTime, &time_left_to_sleep); 
    sleepTime.tv_sec = time_left_to_sleep.tv_sec; 
    sleepTime.tv_nsec = time_left_to_sleep.tv_nsec; 
} 

Certo se stai dormendo solo per 1 microsecondo svegliarsi troppo presto, non dovrebbe essere un problema, ma nel caso generale questo è l'unico modo per farlo fare.

E proprio per fare la torta a favore di boost, boost::this_thread::sleep() viene implementato utilizzando nanosleep(). Si sono presi cura di tutte le pazze casse d'angolo per te.

+0

+1, ho pensato che boost 'sleep()' sarebbe stato implementato con 'nanosleep()', buono per avere conferma. –

+0

Dove vedi il sonno implementato con nanosleep? In thread.hpp sto vedendo: inline void sleep (xtime const e abs_time) {sleep (system_time (abs_time)); } – clemahieu

+0

@clemahieu: Questa non è una chiamata a ':: sleep' (altrimenti ci si limiterà alla risoluzione dei secondi). È una chiamata a uno dei molti altri overload 'boost :: this_thread :: sleep', la cui definizione si può trovare in' libs/thread/src/pthread/thread.cpp'. –

2

Per me la ragione principale dell'utilizzo della variante boost è l'indipendenza dalla piattaforma. Se è necessario compilare l'applicazione per entrambe le piattaforme POSIX e Windows, ad esempio, la sospensione della piattaforma non è sufficiente.

Problemi correlati