Početak›Forumi›Linuks›Programiranje›Odg: Qt QThread
- This topic has 11 odgovora, 3 glasa, and was last updated 16 years, 4 months ranije by jboban.
-
AutorČlanci
-
12. decembar 2007. u 10:55 pm #9620jbobanUčesnik
Da li je neko koristio QThread klasu iz Qt biblioteke? Imam neka pitanja, a primeri su mi nedovoljni. Suviše su elementarni.
13. decembar 2007. u 3:10 pm #65859sysctlUčesnikJa sam koristio. Sta te konkretno interesuje ?
13. decembar 2007. u 5:28 pm #65860jbobanUčesnik1. Da li QThread::start() startuje thread detached ili non-detached?
2. Za multithread programiranje važi da treba zaključati mutex-ima delove koda koji pristupaju zajedničkim delovima memorije, npr. preko pointera. U primeru mandelbrot vrši se lock-ovanje kod pristupa članovima klase. Da li je neophodno i zašto?
3. Da li treba lock-ovati emitovanje signala s obzirom da se oni izvršavaju trenutno, a ne odloženo, a eventualno mogu menjati zajedničke podatke iz zajedničke klase iz koje su thread-ovi i kreirani?
4. Da li je dovoljno regularno napustiti run() metodu za nestajanje thread-i ili je treba i eksplicitno obrisati sa deleteLater()?
…Biće još 😉
13. decembar 2007. u 10:15 pm #65861zevsUčesnik1. 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).13. decembar 2007. u 10:32 pm #65862jbobanUčesnik2. 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…
Radi se o primeru examples/threads/mandelbrot iz Qt instalacije. U ovom primeru su zaključavani delovi koda koji pristupaju privatnim članovima klase, a ne znam zašto. Svaka thread ima svoju instancu klase, svoje privatne promenljive i one nisu zajedničke.
4. kad napustis run() metod nit se zavrsava, ali objekat ostaje (tj memorija koju zauzima).
Ovo sam loše pitao jer sam ovo već imao rešeno sa:
[code]connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));[/code]13. decembar 2007. u 11:07 pm #65863zevsUčesnikSad 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().
13. decembar 2007. u 11:57 pm #65864jbobanUčesnikJeste, tačno to. Sad sam i ja pogledao detaljnije.
14. decembar 2007. u 3:21 pm #65865sysctlUčesnikOvako
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 :D). 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)14. decembar 2007. u 6:38 pm #65866jbobanUčesniknajverovatnije zbog internog event loop-a koji QThread poseduje.
Da, čak za verziju 4.4 najavljuju podrazumevano obavezno korišćenje event loop-a u QThread klasi.
U svakom drugom slucaju se mora koristit neka vrsta sinhronizacije
Čak i u slučaju podataka članova dva različita objekta, tipa Objekat1.podatak, Objekat2.podatak? Za sve deljene zajedničke resurse je razumljivo da mora.
(posebno sa glavnim GUI thread-om)
Kakva je situacija sa non-GUI? Npr. ja koristim QCoreApplication jer aplikacija nije grafička.
22. decembar 2007. u 11:05 pm #65867sysctlUčesnikPa 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…)Kakva je situacija sa non-GUI? Npr. ja koristim QCoreApplication jer aplikacija nije grafička.
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 ? -
AutorČlanci
Moraš biti prijavljen da bi postavio komentar u ovoj temi.