Komunikace mezi pthread vlakny

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Sobota Duben 12 17:57:40 CEST 2003


On Sun, 6 Apr 2003, Stanislav Meduna wrote:

> On Sun, 6 Apr 2003 14:13:01 +0000 (UTC), Pavel Kankovsky wrote:
> 
> : To leda pokud writer provadi aktivni cekani. Pokud visi v select(),
> : poll() (a ceka na zapisovatelnost), nebo primo ve write(), tak jaksi
> : schazi duvod provadet context switche.
> 
> Writer nemoze pokracovat, tak sa zobudi reader. Precita tych desat
> bajtov co mu tam writer poslal a odvisne v selecte sam. No a v tom   
> momente moze zase ist writer. [...]

A proc je writer tak blby, ze po kazdych deseti bajtech zkousi select(),  
misto aby mel na te roure zapnuty non-blocking, nacpal tam, co se do ni
vejde, a select() udelal az pote, co se buffer ucpe a on se musi uspat a
pockat na jeho vyprazdneni? Resp. pokud dela select() kvuli jinym vecem,
proc nema pro rouru vlastni buffer takove velikosti, jak potrebuje?

To, ze PIPE_BUF je stejna hodnota jako skutecna velikost bufferu (resp.
mozna spise skutecnost, ze nekdo v davnych casech rozhodl, ze velikost 
bufferu bude presne ta hodnota, do ktere bude garantovana atomicnost  
zapisu), je sice hloupe, ale rozumny program by s takovymi problemy mel
predem pocitat.

> Andi Kleen mi na to napisal:
>   Programs that really need the bandwidth don't use pipes. Page
>   switching is relatively costly, especially on SMP. Clean POSIX
>   shm support would be probably better.

Tedy puvodne ta diskuse byla u toho, ze mezi dvema thready existuje nejake
uzke a jednoduche rozhrani (nebo tak nejak), coz si zrovna nepredstavuju  
jako neco, cim se cpou stovky MB za sekundu. :)


On Mon, 7 Apr 2003, Michal Dobes wrote:

> Nebylo drive zmineno, ze bude do te roury zapisovat vic klientu
> soucasne? Pokud ano, tak nemuze zapsat vic nez je ten PIPE_BUF,
> protoze jinak neni garantovano nepomichani dat jednotlivych zapisu
> mezi sebou.

PIPE_BUF je rozhodne vetsi kousek nez vyse zminenych 10 bajtu.
Nejsem si jisty, jestli nekdo zminoval, ze by tam melo zapisovat vic
procesu najednou, ale i kdyby to bylo potreba a opravdu to neslo lepe
udelat jinak (s vyjimkou trivialnich pripadu je to dobra cesta, jak
ziskat narok na pobyt v sanatoriu pro osoby postizene "dusevnimi
urazy"), pak se stejne musi pouzit non-blocking (viz vyse), protoze
vysledek volani select() je v takovem pripade zcela nazavazny.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."



Další informace o konferenci Linux