Discussion :

[Chatanga]

Bonjour,

Je butte actuellement sur un problème de lecture/écriture concurrente avec un boost::asio:ip::tcp::iostream. L'écriture sur une instance de cette classe est bloquante tant qu'une lecture (bloquante elle aussi) est en cours.

Si j'ai bien compris, c'est une limitation du iostream encapsulant le streambuf TCP. La sentry associée veille à ce que le streambuf soit accédé de manière exclusive. Ca me choque un peu dans la mesure où les zones get & set d'un streambuf ne constituent pas forcément une même fifo (et même si c'était le cas on pourrait imaginer un comportement non bloquant) mais, si je ne me suis pas mélangé les pinceaux, c'est pourtant bien ce qui se passe.

Il est néanmoins possible de lire et d'écrire simultanéement sur une socket boost (le streambuf TCP gérant bien deux buffers décorélés) alors pourquoi ce comportement de la part d'un boost::asio:ip::tcp::iostream ? Il y aurait-il un moyen de construire un iostream permettant lecture et écriture simultanées ?

[Alp]

Salut,

1/ En protégeant avec un mutex tu ne peux pas lire et écrire (chacun son tour) comme tu le souhaites ?

2/ async_read et async_write ne sont pas bloquant, il me semble, donc tu dois pouvoir creuser dans cette voie-là.

[Chatanga]

1/ En protégeant avec un mutex tu ne peux pas lire et écrire (chacun son tour) comme tu le souhaites ?

Malheureusement la lecture est bloquante. En fait, j'ai un thread qui lit en boucle des blocs de tailles variables (les appels étant bloquants tant que le réseau n'a pas fournit assez de données).

L'écriture se fait de temps en temps dans un autre thread mais a donc toujours lieu, sauf coup de chance, durant un appel bloquant en lecture du thread précédent.

2/ async_read et async_write ne sont pas bloquant, il me semble, donc tu dois pouvoir creuser dans cette voie-là.

Ca m'obligerait à gérer moi-même l'aspect bloquant (dont j'ai besoin, c'est un stream après-tout). Mais pourquoi pas, ça peut être plus clean que la solution ci-dessous :

la seule solution que j'ai réussie à trouver depuis peu est de créer un istream et un ostream avec chacun leur propre streambuf mais qui pointent sur un même socket en interne (ce streambuf est une classe à moi). La seule raison qui m'oblige à avoir deux streambuf distincts est d'éviter le lock (c'est le streambuf qui sert de clef).

Ca fontionne mais il faut encore que je vois si c'est vraiment complétement sécurisé d'un point de vue multithreads (et puis ça reste un peu lourd d'avoir ces duplications).

[Alp]

Et si un thread écrit dans le socket pendant qu'un autre thread lit le socket... quelle maitrise as-tu sur le comportement ainsi induit ?

[Chatanga]

Et si un thread écrit dans le socket pendant qu'un autre thread lit le socket... quelle maitrise as-tu sur le comportement ainsi induit ?

En fait, mon streambuf est réentrant donc, si le asio::ip::tcp::socket est thread-safe, mon streambuf l'est aussi. La question devient donc : peut-on lire et écrire simultanément dans un tel socket sans problème ?

En pratique, ça marche mais, dans l'absolu, ça reste à prouver. Personnellement, je n'utilise asio que depuis très peu de temps et je ne peux rien affirmer. En particulier, je ne sais pas si les strands sont juste là pour faciliter le multi-threads ou sont en fait nécessaire pour en faire.