{"id":3775,"date":"2013-08-19T08:00:45","date_gmt":"2013-08-19T07:00:45","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=3775"},"modified":"2013-08-19T21:53:52","modified_gmt":"2013-08-19T20:53:52","slug":"notifications-rapides-dune-variable-condition","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2013\/08\/19\/notifications-rapides-dune-variable-condition\/","title":{"rendered":"Notifications rapides d’une variable-condition"},"content":{"rendered":"

Un client m’a interrog\u00e9 r\u00e9cemment sur la mise en \u0153uvre d’une notification d’\u00e9v\u00e9nements entre threads. Je l’ai tout naturellement aiguill\u00e9 vers l’emploi d’une variable condition pthread_cond_t<\/code>. Toutefois lorsque les notifications se sont produites par rafales rapides, des probl\u00e8mes se sont pos\u00e9s, que je n’ai pu r\u00e9soudre qu’avec l’emploi d’un s\u00e9maphore suppl\u00e9mentaire.<\/p>\n

\n\n<\/p>\n

Contexte<\/h1>\n

Un programme industriel re\u00e7oit des donn\u00e9es en provenance d’un port de communication RS-485. Lorsqu’une trame compl\u00e8te est re\u00e7ue, des op\u00e9rations doivent \u00eatre r\u00e9alis\u00e9es n\u00e9cessitant des \u00e9missions de donn\u00e9es, des attentes \u00e9ventuelles, ceci en parall\u00e8le sur la r\u00e9ception de la trame suivante. J’ai donc propos\u00e9 \u00e0 mon client de concevoir cette fonctionnalit\u00e9 avec deux threads, l’un se chargeant de recevoir les donn\u00e9es, puis de notifier le second afin qu’il traite la suite des op\u00e9rations.<\/p>\n

Pour assurer la synchronisation entre les deux, il m’a sembl\u00e9 judicieux d’utiliser une variable-condition<\/strong>.<\/p>\n

Variable condition<\/h1>\n

Une variable-condition est simplement une donn\u00e9e de type pthread_cond_t<\/code> partag\u00e9e entre deux threads. J’ai pour habitude, lorsque je pr\u00e9sente cette structure de synchronisation durant une session de formation, de la comparer \u00e0 une cloche. Un thread peut s’endormir, passivement, en attente sur la cloche et un autre thread peut venir \u00e0 tout moment le r\u00e9veiller en donnant un coup de marteau sur la cloche.<\/p>\n

Si aucun thread n’est attente au moment du coup de marteau, tant pis, cette notification est perdue.<\/p>\n

C’est pour \u00e9viter cela, que l’on associe toujours une variable condition avec un mutex pthread_mutex_t<\/code>. Ainsi, on pourra garantir qu’au moment du coup de marteau, un thread sera syst\u00e9matiquement en attente d’un r\u00e9veil.<\/p>\n

Voyons un exemple d’utilisation. Le thread qui attend les notifications se pr\u00e9sente g\u00e9n\u00e9ralement ainsi.<\/p>\n

    pthread_cond_t cnd = PTHREAD_COND_INITIALIZER;\n    pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;\n\nint main(void)\n{\n    \/\/ ... initialisation ...\n    pthread_mutex_lock(& mtx);\n\n    while (1) {\n        pthread_cond_wait(& cnd, & mtx);\n        \/\/ notification recue, traitement...\n        \/\/ ...\n    }\n\n    pthread_mutex_unlock(& mtx);\n    return EXIT_SUCCESS;\n}<\/pre>\n
Le second thread, qui doit notifier le premier travaille ainsi :<\/p>\n
void * fonction_thread (void * arg)\n{\n\twhile (1) {\n\t\t\/\/ Attendre les donn\u00e9es externes\n\t\t\/\/ ....\n\t\t\/\/ Notifier le thread main()\n\t\tpthread_mutex_lock(& mtx);\n\t\tpthread_cond_signal(& cnd);\n\t\tpthread_mutex_unlock(& mtx);\n\t }\n}<\/pre>\n
Contrairement \u00e0 ce que l’on pourrait croire au premier regard, il n’y a pas d’erreur dans le code ci-dessus, il y a bien deux pthread_mutex_lock()<\/code> invoqu\u00e9s dans les deux threads. Ce qu’il faut comprendre c’est que pthread_cond_wait()<\/code> contient plusieurs \u00e9tapes successives :<\/p>\n