Article View: pl.comp.lang.c
Article #267853Re: Ciemna strona C++
From: Sebastian Kaliszewski
Date: Tue, 18 Dec 2007 16:08
Date: Tue, 18 Dec 2007 16:08
33 lines
3365 bytes
3365 bytes
Sektor van Skijlen wrote: >>W szczególności jawnie obsłużony mutex - i to jest poziom, na którym >>normalne programy powinny operować. > > Ano i właśnie tu zaczyna się rzecz, którą niekoniecznie kumam: mam, załóżmy, > jeden muteks. Zajmuję go, modyfikuję zmienną (lub czytam) i zwalniam. Skąd > wiadomo, która część pamięci ma mieć zwolnioną barierę? Przecież muteks nie > jest w żaden sposób powiązany z tym fragmentem pamięci, który modyfikuję. Bariera dotyczy całej pamięci widzianej przez dany kontekst (fizyczny wątek). Nie znam procesora któryby pozwalał to zrobić inaczej w sposób ogólny. Bo tak na prawdę to chodzi nie adresy tylko o sam fakt zapisu. Bariera dotyczy czasu a nie miejsca. >>W systemach Uniksowych z "normalną" pamięcią można też przyjąć, że >>bariera jest wymuszana przez I/O lub IPC. Czyli jeśli jesteś w stanie >>zapewnić *związek przyczynowo-skutkowy* pomiędzy akcjami dwóch wątków >>przy użyciu I/O (np. wpisując coś do pipy w jednym wątku a czytając w >>drugim), to ten związek przyczynowo-skutkowy odnosi się też do >>modyfikacji i widoczności zmian *innych* danych dzielonych przez te >>wątki. To nie jest jawnie gwarantowane przez POSIX, ale na normalnych >>systemach można tak przyjąć (bo każda implementacja zapewni to "przy >>okazji") i jest to czasem wygodne - np. można użyć pipę do >>synchronizacji/sygnalizowania danych w pamięci dzielonej. > > To jest ok, tylko znów - czy takie zwalnianie bariery obowiązuje za każdym > razem całą pamięć procesu? Tak. Bo ono dotyczy nie samej pamięci tylko faktu zapisu. pzdr \SK
Technical Details
Message-ID:
<fk8q9p$81o$2@bozon2.softax.pl>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!bozon.softax.com.pl!not-for-mailReferences:
<fghgeo$spf$1@nemesis.news.tpi.pl> <fgv6ba$k14$1@bozon2.softax.pl> <fgvkne$u3b$1@news.vectranet.pl> <fh1tjd$dtt$1@bozon2.softax.pl> <fh2lj6$qkh$1@news.vectranet.pl> <fha3as$pap$1@bozon2.softax.pl> <fhaj8u$e02$1@news.vectranet.pl> <fhf09d$ohq$1@bozon2.softax.pl> <fhfi9l$640$1@news.vectranet.pl> <fhurmu$5d9$1@bozon2.softax.pl> <fhv020$8k1$1@news.vectranet.pl> <fi1bs4$nn3$1@bozon2.softax.pl> <fi27ds$gt1$1@kujawiak.man.lodz.pl> <fi458p$fmv$1@bozon2.softax.pl> <fi9ckc$2u5$1@kujawiak.man.lodz.pl> <fimb7n$80v$1@bozon2.softax.pl> <fj5k6j$r3e$1@kujawiak.man.lodz.pl> <1196847281.22322.24.camel@qrnik> <fj6in8$mij$2@kujawiak.man.lodz.pl> <fj6m8p$b7e$1@bozon2.softax.pl> <fj96ug$7e4$3@kujawiak.man.lodz.pl> <4d1bbf43-5397-4e1d-85b1-a61dd07b5b01@d21g2000prf.googlegroups.com> <fjmolo$a5r$4@kujawiak.man.lodz.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!bozon.softax.com.pl!not-for-mail From: Sebastian Kaliszewski <s@get.it.off.to.reply.informa.pl> Newsgroups: pl.comp.lang.c Subject: Re: Ciemna strona C++ Date: Tue, 18 Dec 2007 17:08:26 +0100 Organization: Softax news server Lines: 33 Message-ID: <fk8q9p$81o$2@bozon2.softax.pl> References: <fghgeo$spf$1@nemesis.news.tpi.pl> <fgv6ba$k14$1@bozon2.softax.pl> <fgvkne$u3b$1@news.vectranet.pl> <fh1tjd$dtt$1@bozon2.softax.pl> <fh2lj6$qkh$1@news.vectranet.pl> <fha3as$pap$1@bozon2.softax.pl> <fhaj8u$e02$1@news.vectranet.pl> <fhf09d$ohq$1@bozon2.softax.pl> <fhfi9l$640$1@news.vectranet.pl> <fhurmu$5d9$1@bozon2.softax.pl> <fhv020$8k1$1@news.vectranet.pl> <fi1bs4$nn3$1@bozon2.softax.pl> <fi27ds$gt1$1@kujawiak.man.lodz.pl> <fi458p$fmv$1@bozon2.softax.pl> <fi9ckc$2u5$1@kujawiak.man.lodz.pl> <fimb7n$80v$1@bozon2.softax.pl> <fj5k6j$r3e$1@kujawiak.man.lodz.pl> <1196847281.22322.24.camel@qrnik> <fj6in8$mij$2@kujawiak.man.lodz.pl> <fj6m8p$b7e$1@bozon2.softax.pl> <fj96ug$7e4$3@kujawiak.man.lodz.pl> <4d1bbf43-5397-4e1d-85b1-a61dd07b5b01@d21g2000prf.googlegroups.com> <fjmolo$a5r$4@kujawiak.man.lodz.pl> NNTP-Posting-Host: 83.18.189.42 Mime-Version: 1.0 X-Trace: nemesis.news.tpi.pl 1197993956 12047 83.18.189.42 (18 Dec 2007 16:05:56 GMT) X-Complaints-To: usenet@tpi.pl NNTP-Posting-Date: Tue, 18 Dec 2007 16:05:56 +0000 (UTC) User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en In-Reply-To: <fjmolo$a5r$4@kujawiak.man.lodz.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit