Pas d'accord. C'est généralement le même thread qui fait un GetSemephore (ou équivalent en fonction de l'api) et un ReleaseSemaphore. Forcément.
Le thread prend/demande la ressource, il fait GetSemaphore. Il libère la ressource, il fait ReleaseSemaphore. Il n'y a que le thread qui sait quand il n'a plus besoin de la ressource.
Dans ce cas il a pas besoin d'un semaphore mais d'un mutex.
Et la on parle d'un semaphore.
- Thread 1 prend un lock et lance Thread 2 qui fait le traitement.
- plus tard Thread 1 demande encore le lock mais ne l'obtient que lorsque Thead 2 l'a libéré (une fois qu'il a fini son traitement).
Dans ce cas
1°) tu attend que thread 2 a fini avec un join
2°) tu utilise des conditions qui sont tres bien pour ca
3°) ...
Mais un semaphore c'est surtout pour des ressources, pour signaler que tu utilises une ressource. Tu peux utiliser un lock (en général 2) pour synchroniser des threads (et non seulement que protéger des données).
Un sémaphore est une généralisation d'un lock exclusif, mais lui c'est que pour les données (en réalité pas du tout, mais dans ton mode de programmation threadé visiblement si). mais pas le lock exclusif?
Un semaphore laisse n processus accéder a une ressource. Si n>1, tu empeche aucun probleme de race condition, donc c'est des merdes pour l'accés en tant que tel a des ressources exclusives.
Ensuite pour la synchronisation il existe des truc comme barrier par exemple...
[^] # Re: Multicoeur ?
Posté par briaeros007 . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Le thread prend/demande la ressource, il fait GetSemaphore. Il libère la ressource, il fait ReleaseSemaphore. Il n'y a que le thread qui sait quand il n'a plus besoin de la ressource.
Dans ce cas il a pas besoin d'un semaphore mais d'un mutex.
Et la on parle d'un semaphore.
- Thread 1 prend un lock et lance Thread 2 qui fait le traitement.
- plus tard Thread 1 demande encore le lock mais ne l'obtient que lorsque Thead 2 l'a libéré (une fois qu'il a fini son traitement).
Dans ce cas
1°) tu attend que thread 2 a fini avec un join
2°) tu utilise des conditions qui sont tres bien pour ca
3°) ...
Mais un semaphore c'est surtout pour des ressources, pour signaler que tu utilises une ressource. Tu peux utiliser un lock (en général 2) pour synchroniser des threads (et non seulement que protéger des données).
Un sémaphore est une généralisation d'un lock exclusif, mais lui c'est que pour les données (en réalité pas du tout, mais dans ton mode de programmation threadé visiblement si). mais pas le lock exclusif?
Un semaphore laisse n processus accéder a une ressource. Si n>1, tu empeche aucun probleme de race condition, donc c'est des merdes pour l'accés en tant que tel a des ressources exclusives.
Ensuite pour la synchronisation il existe des truc comme barrier par exemple...