🚀 go-pugleaf

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
news:<flofnwkj7f.fsf@jambon.cmla.ens-cachan.fr>...

> Je sais que (comme tu dis) des efforts ont �t� faits pour rendre la
> classe std::string de g++ thread-safe.

(Et les autres, j'esp�re.)

> Je sais �galement que je ne peux pas apporter, aujourd'hui, une
> preuve formelle de la thread-safety (pour ce que cela veut dire) de
> std::string. 

Je ne d�mande pas forc�ment une preuve formelle (que je ne
comprendrais probablement pas, de toute fa�on). Mais quand m�me des
commentaires sur ce qu'on pensait quand on l'�crivait.

Le probl�me, pour nous, est simple. Nos applications doivent tourner
24 heures sur 24, 7 jours par semaine. Alors, la petite fen�tre
d'ins�curit�, on ne peut pas le permettre. En ce qui concerne le
thread-safety, g++ a d� r�tard. Les auteurs de la biblioth�que Sun
(Rogue Wave, en fait) ne sont pas plus comp�tents que ceux de g++, et
je ne leur fais pas plus de confiance. Mais leur biblioth�que sert
maintenant depuis pas mal d'ann�es, avec pas mal d'utilisateurs, dans
des contextes multi-threading. Ce qui veut dire qu'il y a forte
probabilit� que quelqu'un d'autre a d�j� trouver leur b�tises.

Dans le cas de g++, je n'ai pas cette assurance. Tu sais aussi bien
que moi qu'avant 3.0, il n'�tait pas question du thread-safety. Alors,
quelque commentaires pour montrer qu'on a bien couvert les bases
seraient de bien venu. Surtout lorsque la solution adopt�e (au moins
dans le cas de Sparc) s'�loigne tant de l'orthodoxie �tablie. Un
spin-lock. Et comment �vite-t-il qu'un fil de plus haute priorit� ne
se bloque pas perpetuellement parce qu'un fil de plus basse priorit�
ait le lock, mais ne peut pas s'executer pour le relacher ?

> Mais je sais entre autres qu'apr�s avoir ennuy� suffisamment Nathan,
> nous avons regard� ensemble la perception de non thread-safety de
> GNU std:::string, la conclusion est que pour les cas rapport�s, il y
> avait un m�prise sur l'utilisation de certaines fonctions. Cela ne
> veut pas dire que la classe elle-m�me est thread safe.

Certes. Je sais aussi bien que moi qu'en question de thread-safety,
c'est s�rtout la na�vet� qui regne. Dans les deux sens : mon
application (et donc les biblioth�ques dont elle se servent) est
thread safe, parce qu'elle n'a pas encore crash�e, et il doit y avoir
un probl�me dans la biblioth�que, parce que moi, je ne fais pas
d'erreurs:-).

(En passant, je dirais que la vraie m�sure de la na�vet�, c'est le
nombre d'applications qui utilisent les threads. Parce que c'est
rarement la bonne solution. M�me dans notre cas : ce n'est pas la
bonne solution, mais on est oblig� par un logiciel tiers.)

> Mais si tu devais regarder la thread-safety de GCC-3.0, je crois que
> tu peux essayer GCC-3.0.1 ou GCC-3.0.2 (je ne sais plus laquelle est
> la derni�re version).

J'ai un d�mo important milieu octobre. Jusqu'alors, je suis 100% pris
� optimiser l'application (parce qu'il s'agit r�element d'un probl�me
de vitesse). Par la suite, j'imagine que je serais amen� � regarder de
nouveau les histoires de threads.

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orient�e objet
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany, T�l.: +49 (0)69 19 86 27