Linuxo Forumi

Ja sam koristio. Sta te konkretno interesuje ?

1. joinable (non-detached)
2. Ne znam za koji primer mislis ali potrebno je zakljucati pristup zajednickim delovima memorije ako nisu u pitanju atomicne operacije da bi se osiguralo da samo jedna nit tim podacima pristupa u jednom trenutku...
3. ne
4. kad napustis run() metod nit se zavrsava, ali objekat ostaje (tj memorija koju zauzima).

Sad sam na brzinu pogledao taj primer, mislim da sam nasao objasnjenje... Nadam se da ne gresim, nisam imao vremena da detaljno prostudiram.

Zasticeni su mutexima jer obe niti rade sa objektom klase RenderThread, tj imas jednu nit koja izvrsava funkciju run() i drugu koja poziva javni metod render().

Ovako

1. Interni thread koji QThread klasa sadrzi se kreira sa PTHREAD_CREATE_DETACHED, joinable state (pthread_join) se simulira
sa QThread::wait, ako se dobro secam, najverovatnije zbog internog event loop-a koji QThread poseduje.

2. Sto se tice upotrebe mutexa i/ili sinhronizovanja pristupa deljenoj memoriji stvari stoje ovako: pristup i manipulacija svim implicitno deljenim klasama (QString, QImage i sve ostale koje imaju implicit sharing) se moze
obaviti bez zakljucavanja/sinhronizovanja iz vise razlicitih niti, sto znaci da se sve klase ovog tipa posmatraju kao reentrant, (ali ne i thread-safe, za pristup istom objektu se opet mora koristit lock  ). U svakom drugom slucaju se mora koristit neka vrsta sinhronizacije (QMutex, QWaitCondition, QSemaphore,...)

3. Emitovanje signala ne bi trebalo lock-ovati (Qt vrsi neku vrstu serijalizovanja istih ako se tacno secam), ali je potrebno sinhronizovati slot koji prima signal sa ostalim nitima (posebno sa glavnim GUI thread-om)

4. Ovo je vec odgovoreno

Postoji jos nekoliko bitnih stvari, sve objekte izvedene od QWidget i ostalih GUI klasa nije moguce kreirati u
jednom thread-u, a pozivati funkcije iz drugog, preciznije sve GUI klase se mogu koristiti samo iz glavnog GUI thread-a.

Sto se tice mandelbrot/fraktal primera, pretpostavljam (posto nemam src isped sebe, ali se secam kako izgleda )
da se vrsi sinhronizacija izmedju worker thread-a i glavnog GUI thread-a (bas iz razloga koji sam naveo gore),
gde worker racuna fraktal, pa obavestava gui thread da moze da ga iscrta na formi (ili tako nesto)

Pa da covece, npr, ako zelis da pristupis/kopiras Objekat2.podatak1 u Objekat1.podatak1 (i oni su u razlicitim nitima) moras da koristis neku vrstu
sinhronizacije, osim ako su objekti instance implicit shared klasa (QString, etc...)


Ponovo koristis Qt za mrezno programiranje  Na sta konkretno mislis sa QCoreApplication ? Ponovo na sinhronizaciju niti ? U svakom slucaju vaze ista pravila, mada ti ne mogu sa sigurnoscu reci da li je isto kao sa QApplication
jer nikad nisam pisao nesto tog tipa, mozda zevs zna ?

Naravno. Šta je tu loše? Ne sećam se da sam i ranije dobio neki konkretan odgovor na ovo pitanje, a šta je dobro, znam
Uvek se pominje glavni GUI thread, npr. kad se pomene sinhronizovanje i sl., a ne vidim razliku od non-GUI. U čemu se razlikuje GUI od non-GUI thread?
Pomenuo sam QCoreApplication koji govori da ne koristim GUI pa me zanima razlika jer je nisam primetio. I ovako koristim event loop koji QThread od neke verzije ispred podržava.