[Github-comments] [geany/geany-plugins] How to debug a multithread application [ Debugger / gdb ] (#1069)

[elextr]

@avafinger also just to comment on a couple of things you said above which may indicate a misunderstanding of threads.

> Threads are not predictable, but in the sample, Thread[0] will always finish first, because it is fired first, in theory.

No, theory says exactly the opposite, nothing guarantees that, it can be scheduled to run or not at the OS convenience, that depends on what the heaps of other threads running in applications like the desktop and other apps want to do at the same time, no current CPU has enough cores to cope, even hyperthreaded.  So it totally depends on scheduling if a newly created thread gets to run right away, or not.

> Maybe printf is not the best thing to use in the example.

IIUC in practice[^1] printf is fine for threads, each printf will be atomic, so individual characters won't mix, and therefore the order of output shows the order of execution, useful for debugging.  

Therefore your two runs output are both perfectly reasonable, remember the main is also a thread and subject to scheduling, so looking at the first few lines, in run 1 main returned from pthread_create and ran its "successful" printf before thread[0] got to its first printf, but in the second case thread[0] got to run two printfs before the main thread got to run its "successful" printf. See comment above about scheduling.

[^1]: POSIX requires printf to take a lock on the file, but some argue it doesn't explicitly require the lock to be held while all characters are output, but in practice most implementations do.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1069#issuecomment-1088145277
You are receiving this because you are subscribed to this thread.

Message ID: <geany/geany-plugins/issues/1069/1088145277 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20220404/12a8ac33/attachment-0001.htm>