Příspěvky

31

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 01. 11. 2017, 12:29:37 »

Jakmile někdo začně stylem "já nemám v C problém, jenom patlalům se stávají segfaulty", tak je mi jasné, že nemá žádnou zkušenost s větším projektem v C/C++. Chybám při práci s pamětí nejde v C zabránit, už jenom kvůli tomu, že na projektu pracuje více lidí a stačí, aby se nedomluvili nebo nepochopili. Děje se to bohužel úplně běžně v každém projektu jenom trochu složitějším než Hello World.

V C++ se ten problém redukuje už kvůli tomu, že tam se dá projekt rozdělit na objekty, které se z principu každý stará o svůj svět. Pokud je každý objekt odladěn a otestován, problémy známe z C se v C++ prostě projevit nemohou.

Jo a samozřejmě, lidi nechtěji používat C++ protože ho neumí. A neumí ho proto, že se C++ u nás, ale i kdekoliv na světe blbe vyučuje

https://www.youtube.com/watch?v=YnWhqhNdYyk

32

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 31. 10. 2017, 23:43:21 »

C++ je překonaný jazyk, byl překonán Javou a C#.
Multithreading v C++ je opruz, C# má poměrně velkou paletu nástrojů a to nejen pro tohle.

Kdy jste naposledy viděl C++. Já jen že už od verze z roku 2011 je multithreading naprostá pohoda.

Co se jmenovaných jazyků týče, tak C# = otrok Microsoftu, Java = otrok Oracle, C++ = svoboda.

33

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 31. 10. 2017, 23:23:46 »

Lidi naučte se C++ a přestanete řešit voloviny

C je jednoduchý a s určitou praxí a cvikem příjemný nízkoúrovňový jazyk. Kdežto C++ je... raději no comment, nerad užívám sprostých slov. Ale když chce někdo objektově programovat, měl by použít objektový jazyk a ne C++.

Nejde o objekty, ale třeba kdyby použil std::string, tak se vyhne většině bezpečnostních problémů a další drtivé většina běžných začátečnických problémů. Mimochodem, práce s řetězci je z pravidla příčinou různých chyb typu buffer overrun, což je i tenhle případ, jako demonstrace postačí.

34

Vývoj / Re:C-čko a zápis mimo proměnnou

« kdy: 31. 10. 2017, 21:28:00 »

Lidi naučte se C++ a přestanete řešit voloviny

35

Vývoj / Re:C - Thread a select()

« kdy: 31. 10. 2017, 16:30:48 »

V žádném případě nedoporučju používat. Stabilní program nechá své vlákna deterministicky dojít do konce kódu. Dokážu si představit, že ve zrušeném vláknu se nezavolají různé čistící bloky kódy, které jsou za selectem, v C++ například destruktory, atd.

Pokud vlákno musí něco po sobě čistit, tak od toho snad mám pthread_cleanup_push(), kterým průběžně ukládám čisící kód, který se při ukončení vlákna vykoná v pořadí, jak byl napushován a je jedno, zda vlákno končí kvůli return/pthread_exit()/pthread_cancel() ).

Mně se tohle nelíbí, to je totiž stejný mechanismus jako atexit. Jenže zatímco u exitu finalní čistění udělá operační systém, u threadů je to větší průser. Jakou jistotu máte, že to dělají všechny části kódu? Rozlišujete nějak v knihovnách, jestli běží ve vlákně, nebo v ... hlavním vlákně, kde se to běžně nedělá? Co když tam zamýchám C++ který prokazatelně destrukci objektů nenavěšuje na tenhle event?

Ne, fakt to nepoužívejte, nadělá to víc škody než užitku. V C++ už tuplem ne. To je lepší MT navrhovat tak, aby vždy existovala cesta, jak opustit nějakou aktuální činnost a spořádaným způsobem ukončit všechny funkce returnem až na tu základní úroveň. (případně výjimkou zachycenou na základní úrovni)

pthread_exit() si zavolá ten kdo volal tu mojí vstupní funkci, to už je jeho starost.

36

Vývoj / Re:C - Thread a select()

« kdy: 31. 10. 2017, 15:14:02 »

Ano, je to možné řešení. Jiný postup, pokud je cílem vlákno jen ukončit a netřeba, aby cokoliv dalšího dělalo, tak použít pthread_cancel(), protože select je povinný cancel point, tak bude vlákno přímo ukončeno, pokud bude v select čekat (pokud má vlákno default stavy nastaveno PTHREAD_CANCEL_ENABLE a PTHREAD_CANCEL_DEFERRED,  viz funkce pthread_setcancelstate()  a pthread_setcanceltype() ).

V žádném případě nedoporučju používat. Stabilní program nechá své vlákna deterministicky dojít do konce kódu. Dokážu si představit, že ve zrušeném vláknu se nezavolají různé čistící bloky kódy, které jsou za selectem, v C++ například destruktory, atd.

37

Vývoj / Re:C - Thread a select()

« kdy: 31. 10. 2017, 10:16:43 »

Jestli chceš ukončit čekání a zavřít spojení, pak nejspravnejsi postup je shutdown socketu na SHUT_RD. To způsobí že select skončí a recv operace vrátí nulu jako by spojení zavřela druhá strana

Pokud chceš budit to vlákno jindy, pak to dělám tak že mám jedno extra lokální spojení (v Linuxu roury) a jeden konec poslouchám selectem a do druhého pošlu bajt a select thread se probudí. Na Windows stačí udp socket který sám sobě pošle zpravu.

V Linuxu je select bezpečnostní hrozba, doporucuju použít poll nebo epoll. Ve windows se select používá jako poll, doporučuji si napsat Windows emulaci pollu právě přes jeho select

38

Vývoj / Re:Synchronizace - obrácený semafor

« kdy: 30. 10. 2017, 20:58:24 »

Vola sa to Barrier alebo WaitGroup.

Skoro urcite to riesis zle. Na cakanie na dokoncenie operacie (alebo operacii) je lepsi promise/future. S nimi nemusis riesit take tie problemy ako "pripocital som?", "nie je tam race condition?" a podobne. Ked sa ti podari deadlock, tak byva deterministicky. Caka to prave na hodnoty, ktore chces pouzit.

Ne sorry, "pripocital som?" fakt je ukazuje na lehce neschopné programování. Tohle fakt nastat nemůže. Už třeba proto, že bežící task může provádět increment/decrement přes RAII, takže je to i exception safe. Při vzniku tasku zavolá inc, při dokončení tasku nebo jeho destrukci zavolá dec. Race condition tam určitě není.

Stejným způsobem třeba podobný problém nenastane při refcountingu, což je podobný problém, akorát tam jde o zničení objektu když refcount klesne na nulu. Tady jde o odblokování vlákna.

Hele, nechci te nak moc presvedcovat, protoze neznam uplne situaci, ale uz to tu nekdo rikal. Nestaci na to opravdu std::atomic ?

No, šlo by tam mít atomic counter, ale funkci wait() mi atomic neudělá, leda přes nějaký spinlock. Na zastavení vlákna potřebuju mutex a condvar. No a když už tam mám mutex, tak ten atomic je už zbytečný. Možná ještě rychlejší by to bylo, kdyby counter byl atomic, tim bych se vyhnul zamykání při inc/dec.

Ale já jsem chtěl vědět, jestli se tohle někde nepoužívá, že bych uspůsobil rozhraní a název abych to měl standardní

39

Vývoj / Re:Synchronizace - obrácený semafor

« kdy: 30. 10. 2017, 18:21:00 »

jsou v C++ ve vychozim stavu thread safe?

Jestli C++ jsou atributy thread safe? Odpověď zní NE. A ani to není žádoucí protože zajištění thread safety je výkonově drahé a obecně se snažíme jakékoliv interakce mezi thready minimalizovat aby se to muselo řešit na co nejméně mistech.

V tomto konkrétním případě jde o to že atribut counter není thread safe ale taky jeho čtení v okamžiku používání vícero vlákny je samo sebou nesmyslné protože může vracet stará data a teoreticky může dojít k poškození údaje při čtení a zároveň zápisu jiným vláknem. (Prakticky se to ale při čtení intu nestane). Nicméně se nepředpokládá nějaké praktické využití v tomto režimu je to spíš kvůli možnosti výpisu vnitřního stavu pro účely nějakého ladění a logovánI

40

Vývoj / Re:Synchronizace - obrácený semafor

« kdy: 30. 10. 2017, 16:16:49 »

V metodě getCounter není korektní takhle přistupovat k proměnné counter bez mutexu. Mutex musí být pro zápis i čtení, jinak je tam race condition.

Já bych to ještě doplnil, že samotná funkce getCounter je velice sporná, pokud by měla sloužit k čemukoliv jinému než nějaké statistice.

Ta funkce má smysl, pokud ji používá jediné vlákno, které zároveň s counterem manipuluje. Tam pak mutex není potřeba, protože jen to jedno vlákno ho čte a mění. Zároveň v situaci, kdy těch vláken mám víc, pak ta funkce smysl nemá a volat ji taky smysl nemá. Proto je tam mutex v zásadě zbytečný.

41

Vývoj / Re:Synchronizace - obrácený semafor

« kdy: 29. 10. 2017, 20:12:03 »

Condition variable.
https://en.m.wikipedia.org/wiki/Monitor_(synchronization)

Ano, používám na to condition_variable, chtěl jsem to vyčlenit z projektu a strčit do nějaké společné knihovny a dát tomu rozumný název. Zatím se to jmenuje MTCounter

Kód: [Vybrat]

class MTCounter {
public:

void inc() {
std::unique_lock<std::mutex> _(lock);
counter++;
}
void dec() {
std::unique_lock<std::mutex> _(lock);
if (counter) {
counter--;
if (counter == 0) {
waiter.notify_all();
}
}
}
bool zeroWait(unsigned int timeout_ms) {
std::unique_lock<std::mutex> _(lock);
return waiter.wait_for(_,std::chrono::milliseconds(timeout_ms), [=]{return counter == 0;});
}
void zeroWait() {
std::unique_lock<std::mutex> _(lock);
waiter.wait(_,[=]{return counter == 0;});
}

unsigned int getCounter() const {
return counter;
}

void setCounter(unsigned int counter) {
std::unique_lock<std::mutex> _(lock);
this->counter = counter;
if (counter == 0) {
waiter.notify_all();
}
}

protected:
std::mutex lock;
std::condition_variable waiter;
unsigned int counter = 0;
};

42

Vývoj / Re:Synchronizace - obrácený semafor

« kdy: 29. 10. 2017, 20:09:33 »

Typicky to používám tak, že chci aby thread počkal, dokud se nedokončí všechny paralelní operace, přičemž stačí počítat, kolik jich ještě běží. Pokud všechny skončí, klesne čítač na nulu a thread může pokračovat.

Pro tuhle konkrétní situaci by šlo možná použít nějakou obdobu thread_group z boostu. Nemusel byste se starat o inkrementaci a dekrementaci čítače.

No já to nepoužívám jen na vlákna, ale obecně na počítání úloh. Těch může být víc jak vláken, přičemž některé se vykonávají, jiné jsou ve frontě. Cílem je zastavit nějaké vlákno, dokud nejsou úlohy hotové.

43

Vývoj / Synchronizace - obrácený semafor

« kdy: 29. 10. 2017, 18:49:18 »

Ve svém kódu jsem začal používat objekt, který funguje obráceně než semafor. Je to counter, který mohu zvyšovat a snižovat a případně mohu nařídit jinému vláknu, aby bylo zastaveno, dokud se na counteru neobjeví nula.

Typicky to používám tak, že chci aby thread počkal, dokud se nedokončí všechny paralelní operace, přičemž stačí počítat, kolik jich ještě běží. Pokud všechny skončí, klesne čítač na nulu a thread může pokračovat.

A teď hledám na google, jak se toto synchronizační primitivum jmenuje. Protože klasický semafor to není, bariera taky ne. Google mi nepomůže, protože se ho neumím zeptat. Pomůže mi někdo?

44

Odkladiště / Re:Investujete do ICO?

« kdy: 29. 10. 2017, 09:23:24 »

ICO je mechanismus jak převést peníze od důvěřivých a naivních investorů k neschopným nebo příliš ambiciózním vývojářům. Ve výsledku jde o to že peníze se prožerou a projekt nakonec zkrachuje nebo je dodáno něco, co vlastně nikdy fungovat nemohlo

45

Vývoj / Re:problém s C++ : ios::ate

« kdy: 28. 09. 2017, 16:55:08 »

ios::app funguje. Vlastně původně jsem si myslel, že fungovat nebude, protože to používám k detekci toho, zda soubor už existuje nebo ne (C++neumi O_EXCL). Pokud mi tellp vrátí nenulový výsledek, tak vyhodím výjimku. Přišlo mi, že v režimu app nemůže tellp fungovat, protože to víc funguje jak stream.


Co vlastně dělá ios::trunc.... mě tedy nedělá nic, protože samotné ios::out udělá automaticky trunc. Doteď jsem ho všude uváděl, ale koukám, že naprosto zbytečně.

Jen tak si všimněte, že v strace není použit příkaz O_CLOEXEC. Dnešního hlediska bezpečnostní nutnost. (STL je vlastně nebezpečná)