Olé les amis !    
 
Voila je me demandais si la fonction write(...) était atomique du point de vue taches effectués par le proc, à la rigueur ca pourrait être logique car write doit faire surement une interruption ... (par contre je suis vraiment pas sur lorsqu'on taquine les pipes et FIFOs)
 
Mais pour le read je doute vraiment que l'ordonaceur face "que" ça.
De plus si on fait des read sur des tubes (qui ont une taille limité à 4096ko je crois) j'ai lu qu'il fallait le faire d'une maniere iterative ? je pige pas trop pkoi ?
 
Quelqu'un as t-il un avis a ce sujet ?

write est garantie atomique jusqu'à une certaine valeur (PIPE_BUF); read ne l'est pas (selon POSIX).

c'est quoi l'atomicité?

Une opération atomique est une opération durant laquelle on est sûr que le processeur n'exécutera pas de code susceptible de modifier les données manipulées par cette opération.

il existe les lock de fichier à cette effet justement pour ne pas rencontrer ce problème...

Oui tu parle des semaphores ou des moniteurs là ... mais c'est justement le probleme : Si j'ai un buffer de n'importe quoi je pourrais faire des write tranquile dedans (pour simuler l'operation V : "incrementer" ) car l'atomicité est à priori garantie, mais pour realiser l'operation P ("probieren" cad decrementrer et donc read dans le cas des pipes) sachant que je n'ai pas de garantie d'atimicité du read je ne peux donc pas etre sur qu'il n'y aura pas un autre processus qui lira le tube avant ... cad garantir l'atomicité de P quoi.
 
Mais bon c'est juste histoire de capter comment marchent les IPCs system V.

merci pour l'info

Je ne pense pas que l'atomicite soit garentie. Rien n'empeche le processus d'etre undispatche entre l'appel a write et son retour, et un autre processur d'etre dispatche et d'aller modifier les donnees que tu veux ecrire, avant qu'elles soient ecrites, et meme avant le copyin. Sans parler des systemes multi-proc.

Il parait que c'est depassé les semaphores ... par les monitors et les channels c'est quoi les channels dans ce contexte ?