Multithread programming - Multithread programming in GLib/GTK+ ...
Multithread programming - Multithread programming in GLib/GTK+ ... Multithread programming - Multithread programming in GLib/GTK+ ...
Multithread programmingAlternatives to threadsThreads in GLib and GTK+ applicationsDesign PatternsDebuggingMultithread programmingMultithread programming in GLib/GTK+ applicationsCarlos García Camposcarlosgc@gnome.orgCarlos García CamposMultithread programming
- Page 2 and 3: Multithread programmingAlternatives
- Page 4 and 5: Multithread programmingAlternatives
- Page 6 and 7: Multithread programmingAlternatives
- Page 8 and 9: Multithread programmingAlternatives
- Page 10 and 11: Multithread programmingAlternatives
- Page 12: Multithread programmingAlternatives
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>g<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong><strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong> <strong>in</strong> <strong>GLib</strong>/<strong>GTK+</strong> applicationsCarlos García Camposcarlosgc@gnome.orgCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>gIntroductionConcurrent <strong>programm<strong>in</strong>g</strong> based on threadsThread: <strong>in</strong>dependent execution flow <strong>in</strong>side a process.Multiple threads can run simultaneously (orpseudo-simultaneously)Creat<strong>in</strong>g a new thread is lighter than creat<strong>in</strong>g a newprocessCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>gAdvantagesAvoid<strong>in</strong>g blocks <strong>in</strong> applications that do I/O operationsImprov<strong>in</strong>g feedback <strong>in</strong> GUI applicationsCommunication among threads <strong>in</strong> the same process isquite easy and fastTak<strong>in</strong>g advantage of the hardware parallelism <strong>in</strong> SMPsystemsCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>gDisadvantagesConcurrent <strong>programm<strong>in</strong>g</strong> is hardNon determ<strong>in</strong>ism executionDebugg<strong>in</strong>g is more difficultTypical concurrent issues: dead blocks, performance, andso onCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>g¿Why alternatives?Disadvantages might be enough worth not to use threadsGeneral advice: use threads only when it’s absolutelyneededMany situations can be addressed <strong>in</strong> an easy way withoutus<strong>in</strong>g threadsCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>gAlternativesUse of g_idle_add functions to quickly f<strong>in</strong>ish a callbackExplicitly dispatch pend<strong>in</strong>g work <strong>in</strong> the ma<strong>in</strong> loopUse of async API when it’s available: gnome_vfs_async_*,g_spawn_async_*, etc.Carlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>GLib</strong><strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>g<strong>GLib</strong> provides and API that, <strong>in</strong> UNIX systems, is a wrapperof p_thread (POSIX threads)Threads management functions:g_thread_createg_thread_create_fullg_thread_exitg_thread_jo<strong>in</strong>....Concurrence functions:g_mutex_*g_cond_*Carlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>g<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong> <strong>in</strong> <strong>GLib</strong>/<strong>GTK+</strong><strong>GLib</strong> is thread-safety when g_thread_<strong>in</strong>it is usedGDK provides gdk_threads_<strong>in</strong>it too that has to be used <strong>in</strong>addition to g_thread_<strong>in</strong>it, but it’s not alwaysrecommendableTwo options:Us<strong>in</strong>g gdk_threads_<strong>in</strong>it, gdk_threads_enter() andgdk_threads_leaveAccess<strong>in</strong>g the program GUI exclusively from the ma<strong>in</strong>thread (where the gtk ma<strong>in</strong> loop is runn<strong>in</strong>g)The second options is preferable <strong>in</strong> most of the casesCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>gThreads communicationMa<strong>in</strong> threadOne or more threads that perform the hard workg_idle or g_timeout functions to send tasks to the ma<strong>in</strong>thread form othersCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>gDesign PatternsBoss/Workers: tasks are assigned by the boss to theworkers. There are several variations of this modelPipel<strong>in</strong>e model: a task is split <strong>in</strong>to several steps so thatthere is a thread for every stepCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>gDebugg<strong>in</strong>gXlib: unexpected async reply(sequence 0x1421)!Carlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>Alternatives to threadsThreads <strong>in</strong> <strong>GLib</strong> and <strong>GTK+</strong> applicationsDesign PatternsDebugg<strong>in</strong>g¿What to do?Look for X error handlers <strong>in</strong> the <strong>in</strong>termediate layersBonobo: bonobo_x_error_handlerGDK: gdk_x_errorCairo: _noop_error_handlerSet a break po<strong>in</strong>t <strong>in</strong> gdb for every handlerRun the program <strong>in</strong> gdb with the –sync modifier (so thatthe X w<strong>in</strong>dow calls will be synchronous)Once you are stopped <strong>in</strong> the break po<strong>in</strong>t you can just get abacktrace like if it were a crashIn order to get a backtrace for every runn<strong>in</strong>g thread use thefollow<strong>in</strong>g command <strong>in</strong> gdb: thread apply all btCarlos García Campos<strong>Multithread</strong> <strong>programm<strong>in</strong>g</strong>
Change language