Dotaz: náhrada sleep() v C++

[smaza]

Zdravím, napsal jsem program v C++, ve kterém je cyklus while na jehož konci je funkce sleep, která provádění programu na 1 min. uspí, pak zase jede cyklus znovu. Chtěl bych se zeptat, jestli kromě sleep existuje nějaký jiný způsob jak pozastavení programu zajistit. Díky.

---

---

Odpovědi

[l4m4]

Pokud program na něco konkrétního čeká, tak například select(), poll() a spol. s případným timeoutem (většinu věcí jde v Unixu dostat jako událost na filedeskriptoru). Ale pokud čekáš jen tak a sleep() dělá přesně to, co potřebuješ, tak proč ho chceš nahrazovat?

[smaza]

Ten program zjišťuje data (např. teplotu cpu) a odesílá je na server. Pomocí sleep určuju interval zjišťování a odesílaní, takže na nic nečekám. Je to moje DP a oponent mi položil otázku "Dala by se v hlavní programové smyčce nahradit funkce sleep za jiný mechanismus?" Já nejsem zase tak zběhlý a o jiném mechanismu nevím, tak jsem se chtěl zeptat tady.

[rADOn]

Můžeš si požádat kernel o doručení signálu SIGALRM (periodicky nebo v určený čas) a uspat se.

[Josef Kufner]

... a uspat se použitím sleep().

[rADOn]

Cituji z TFM:

…sleep(3) may be implemented using SIGALRM; mixing calls to alarm() and sleep(3) is a bad idea.…

[zulu]

A copak tím chceš říct?

[rADOn]

Které části "bad idea" nerozumíš?

[zulu]

Obsahu citace rozumím zcela.

[Ondrej 'SanTiago' Zajicek]

Dala by se v hlavní programové smyčce nahradit funkce sleep za jiný mechanismus?

Jinak na modernich jadrech by sel take pouzit cekani na timerfd, viz treba http://www.kernel.org/doc/man-pages/online/pages/man2/timerfd_create.2.html

[Luboš Doležel (Doli)]

Sleep má nevýhodu v tom, že vlastně není zaručeno, jak dlouho bude čekat. Pokud ti přijde nějaký signál, sleep bude přerušen a ty nebudeš vědět jak dlouho ještě čekat.

Select ti je užitečný, i když nebudeš chtít čekat na žadý filedescriptor, protože vrací, kolik času ještě chceš čekat do splnění onoho intervalu.

Další možností je použít cron, ale na intervaly kolem minuty to není moc funkční.

V neposlední řadě lze využít nějaké ty knihovny/frameworky, které mají v sobě hlavní smyčku a obsahují časovač. Např. Qt Core (lze přeložit i bez GUI) nebo glib.

Jinak se ale za sleep stydět nemusíš. Ono tohle bude spíš o tom, že ve škole se učí, že aktivní čekání se sleepem je špatně. Ovšem v tomhle případě chceš přesně to.

[VM]

Čekání se sleepem není aktivní, ale pasivní, aspoň na normálním systému. Aktivně čeká usleep.

[Michal Kubeček]

Funkce usleep() je úplně stejně pasivní jako sleep() nebo nanosleep(). Luboš měl ale IMHO na mysli to, že někdy autoři programů místo pasivního čekání na nějakou událost využívají smyčku, která se v pravidelných intervalech ptá, jestli už událost nastala. Při krátkém intervalu se tím zbytečně zatěžují zdroje, při dlouhém se zase prodlužuje reakční doba. Někdy to samozřejmě jinak dělat nejde, ale často se to z neznalosti nebo lenosti používá, i když mechanismy pro pasivní čekání existují.

[VM]

nanosleep() podle manuálu pro krátké intervaly čekal aktivně, na jádrech 2.4 to dělá pořád. Každopádně s prostředky pro sleep() bych si moc starostí nedělal, test jedné podmínky jednou za několik sekund (granularita funkce sleep) je zanedbatelná zátěž.

[Michal Kubeček]

nanosleep() podle manuálu pro krátké intervaly čekal aktivně

I kdyby ano, tady se bavíme o náhradě za sleep(), takže o takový interval zcela určitě nejde.

Každopádně s prostředky pro sleep() bych si moc starostí nedělal, test jedné podmínky jednou za několik sekund (granularita funkce sleep) je zanedbatelná zátěž.

Tady si asi nerozumíme. Neměl jsem na mysli zátěž funkce sleep() samotné, ale o ty periodické kontroly, tj. konstrukce typu

  while (!ready()) {
    usleep(100);
  }

když na něco čekáte. Pokud ten interval bude příliš krátký, budou opakované kontroly příliš zatěžovat procesor (a možná i něco jiného). Bude-li příliš dlouhý, pak máte příliš dlouhou odezvu. Pokud existují prostředky, jak se nechat probudit až tehdy, když je podmínka splněná (a hned, jakmile je splněná), měla by jim být dána přednost.

[Ondrej 'SanTiago' Zajicek]

Pokud ti přijde nějaký signál, sleep bude přerušen a ty nebudeš vědět jak dlouho ještě čekat.

man sleep(3) rika neco jineho:

Zero if the requested time has elapsed, or the number of seconds left to sleep, if the call was interrupted by a signal handler.

[Michal Kubeček]

Jenže vzhledem k sekundové granularitě je praktická použitelnost většinou dost sporná.

[rellix]

Ano mozes cakat na signal napr. Ja by som toto riesil dvoma vlaknami, jedno caka na signal a druhe vlakno cita systemovy cas vypocitas si cas kedy ma sigalizovat cez danny signal ze nastal cas potom si da samo sleep na kratsiu dobu napr 1/10 a takto sa dostane k zobudeniu druheho vlakna vo velmi presnom casovom intervale. Napriklad cez Pthread sa da toto naproramovat za 10 minut.

[Josef Kufner]

WTF?

[rellix]

RTFM

[l4m4]

Po ,dvoma vláknami` jsem to přestal číst, protože WTF?, ať už následuje cokoli.

[Matlák]

[Voty]

Z funkcí příbuzných sleep() tu máme usleep(), pak také nanosleep(). Poslední jmenovaný dokonce dokáže říct, jak dlouho čekal v případě přerušení SIGNALem. Také se dá použít select() s určitým timeoutem. Principiálně jsou všechny tyto fce na jedno brdo.

Obecně lze samozřejmě sleep() nahradit lecčím. Například můžeš program navázat na signál z GPS a vždy když se změní počet vteřin, tak provést akci. Otázkou je, zda-li je to rozumné :)

[kocour_easy]

Kdysi jsem si s necim podobnym hral:

int
own_sleep (time_t seconds, time_t useconds)
{
#if LINUX
  struct timeval interval;

  if (seconds < 0)
      seconds = 0;
  if (useconds < 0)
      useconds = 0;
  if (seconds == 0 && useconds == 0)
      return -1;

  memset(&interval, 0, sizeof(interval));
  interval.tv_sec = seconds;
  interval.tv_usec = useconds;

  return select (FD_SETSIZE, NULL, NULL, NULL, &interval);
#endif
#if !(defined __MINGW32__ || defined _MSC_VER)
  struct timeval now, deadline;

  gettimeofday (&deadline, NULL);
#if 0
  deadline.tv_usec += usec;
  deadline.tv_sec += deadline.tv_usec / 1000000;
  deadline.tv_usec %= 1000000;
#else
  deadline.tv_sec += useconds;
  deadline.tv_usec += seconds;
#endif

  do
    {
      gettimeofday (&now, NULL);
    }
  while ((now.tv_sec < deadline.tv_sec) ||
         (now.tv_sec == deadline.tv_sec && now.tv_usec < deadline.tv_usec));
#else
  /* MinGW has no gettimeofday(). ftime() seems to be the best alternative as I
   * don't know of any standard Windows function with microsecond accuracy. I
   * should have a look at the Cygwin source code... - dbjh */
  struct timeb tb;
  int32_t int now, deadline;

  ftime (&tb);
  deadline = tb.time * 1000 + tb.millitm + useconds / 1000;

  do
    {
      ftime (&tb);
      now = tb.time * 1000 + tb.millitm;
    }
  while (now < deadline);
#endif
}

zakladni problem je v tom, ze kazde aktivni volani sleep, za pomoci dodatecnych funkci vytvari rezii na CPU a na volani prislusnych prostredku. Nejlepsi je pouziti timeoutu pro uvedeny select().

[benn]

Kdysi jsem taky potřeboval nahradit funkci sleep(), protože se ukončovala předčasně díky dalším signálům. Tak jsem do vláken raději dával pro čekání:

	pthread_mutex_lock(mutex);
	clock_gettime(CLOCK_REALTIME, &abstime);
	abstime.tv_nsec += msec * 1000000;
	abstime.tv_sec += sec;
	
	if (abstime.tv_nsec  > 1000000000UL) {
	    abstime.tv_nsec %= 1000000000UL;
	    abstime.tv_sec += 1;
	}
	
	rc = pthread_cond_timedwait(cond, mutex, &abstime);
	if (rc != ETIMEDOUT) WARN("Predcasny timeout (rc=%d)", rc);
	
	pthread_mutex_unlock(mutex);

Před použitím se musely inicializovat proměnné "mutex" a "cond". Ale zase pomocí funkce pthread_cond_signal() šlo čekání okamžitě zrušit.

[Ondrej 'SanTiago' Zajicek]

Pouzivat po podobne ucely cokoliv, co zavisi na CLOCK_REALTIME, je zasadni chyba.

[benn]

To ano, pokud se změní systémový čas, tak to bude mít nepříjemné důsledky. Ale není problém změnit zdroj hodin třeba na CLOCK_MONOTONIC (viz pthread_condattr_setclock()). Nakonec jsem měl štěstí, že se systémový čas nikdy během chodu linuxu neměnil.... I tak linux nabízí velkou spoustu možností jak s časem zacházet.