Je suis sur un client/serveur en ce moment (toujours...), mon client peut appeler des fonctions comme achat ou vente qui font appel à une BDD faite sur le chargement et la sauvegarde d'une liste chaînée. Le soucis c'est que si deux clients ont lancé achat, ils ont la même version de la BDD du coup si il ne reste plus qu'un article, ils peuvent "tous les deux l'acheter"

Donc je voulais utiliser des mutex niveau serveur si le mot achat est rentré par un client pour mettre en attente les autres jusqu'à ce client ait fini

Mais je sais pas comment faire
Le mieux ce serait de mettre en attente les autres si le mot a été tapé et de faire une boucle d'attente jusqu'à ce que ce soit finit

Tu dois avant tout identifier les plus petites sections de ton code qui ne doit pas être exécutée par plus d'un thread. On parle de sections critiques, et j'insiste sur le côté petit que ça doit avoir, car sinon tu vas complètement bousiller les perfs de ton programme et perdre tout l'intérêt du multithreading.
Je pense que dans ton cas, il s'agit de la section qui lit le nombre d'articles restants, puis celle qui le met à jour après achat.

Ensuite, tu dois créer une mutex (avec pthread_mutex_init sous les systèmes POSIX, ou CreateMutex sous Windows si je ne dis pas de conneries) au début de ton code de serveur. Elle doit être visible dans les deux sections critiques qu'on a identifiées précédemment.
Au début d'une section critique, tu dois verrouiller l'objet mutex (avec un appel à pthread_mutex_lock dans le monde POSIX, ou je-ne-sais-plus-quelle fonction équivalente chez Windows), puis la déverrouiller à la fin de cette même section. Donc dans ton cas il doit y avoir un verrouillage et un déverrouillage autour de la lecture d'une part, et de l'écriture d'autre part.

Ça résout ton problème de file d'attente, car les appels à pthread_mutex_lock effectués alors que la mutex est déjà verrouillée deviendront bloquants jusqu'au déverrouillage (et l'un des threads en attente pourra alors entrer dans la fameuse section critique).

Je suis sous Unix et j'ai pu récupéré les commandes mutex associés, merci

Donc il faut une partie Mutex dans le serveur pour bloquer / débloquer
Et dans la/ les fonctions concernés appelés par mon client ?

Salut, merci pour ton aide

J'ai bousculé pas mal d echose parce que j'ai manqué de logique, mon client fait désormais l'appel au serveur pour qu'il traite la demande d'achat le serveur gère bien la concurrence avec l'init et la création du thread et le lock/unlock côté fonction achat

J'ai eut un petit soucis pour faire passer plusieurs arguments mais c'est réglé maintenant

ATTENTION: les mutex pthread ne sont pas bloquant jusqu'au deverouillage. Ils sont bloquant jusqua ce que:
-le mutex est deverouiller
-OU le process recoit un signal.

Il est important de regarder le code de retour de l'appel a pthread_mutex_lock pour savoir dans quel cas on se trouve.

my bad, ce sont les conditions qui ont ce comportement [1]. Parles d'une API chelou.

[1] http://linux.die.net/man/3/pthread_cond_wait

Déjà c'est pas ton "client" qui doit réaliser l'achat!! ET la BDD n'est que coté serveur aussi!

Mais le serveurs! donc tu passe en file d'attente les commandes d'achat des clients, et c'est le premier arrivé qui est servit! et si d'autre on "fait le même achat" le serveur leur envois alors une information comme quoi la transaction est impossible.