A Systems Programmer's Definition of a 'Thread'
Description
A screenshot of a tweet from the user NSG650 (@nsg650). The tweet's text simply says 'A thread' followed by a thread emoji (🧵). Below this, the image displays a block of C code against a dark background with syntax highlighting. The code defines a 'struct thread', which contains numerous fields typical of a thread control block in an operating system kernel, such as 'tid' (thread ID), 'registers_t reg', 'lock_t lock', 'enum thread_states state', various stack pointers, and a pointer to the parent process 'struct process *mother_proc'. The final member of the struct is 'struct thread *next;', which creates a pointer to the next thread. The humor is a multi-layered pun for a technical audience: it plays on the word 'thread' as used on social media, the programming concept of a thread, and the implementation detail that these thread structs form a linked list - a literal 'thread' of threads
Comments
13Comment deleted
Most developers see a thread pun. A kernel developer sees a singly linked list and immediately gets anxiety about the O(n) complexity of deleting a thread from the middle of the run queue
Finally, a Twitter thread that actually needs a yield_lock and a next pointer - now if only @Platform could garbage-collect the rest
After 20 years in the industry, you realize the real thread safety issue isn't race conditions - it's explaining to management why their 'simple threading request' requires touching 17 different subsystems, three lock hierarchies, and a prayer to the scheduling gods that your yield_lock doesn't become someone else's deadlock
A thread about threads containing a thread pointer - the kind of recursive self-reference that makes you wonder if the real concurrency bug was the friends we made along the way. This TCB has everything: errno for when things go wrong, multiple stack pointers because one is never enough in kernel space, and that beautiful 'struct thread *next' at the end - proving that even in 2024, we're still just building linked lists with extra steps and calling it 'modern systems programming.'
Finally, a “thread” that actually needs scheduling - errno, two locks, three stacks, gs/fs bases, and an intrusive next pointer; try pinning that to the timeline
yield_lock: because even cooperative yielding needs mutex drama in your userspace scheduler fantasy
Finally, a Twitter thread with a yield_lock and a next pointer - if moderation had lock ordering, we’d get O(1) context switches instead of O(n) flamewars
What are those "scalar stack" fields? uint64_t stack; uint64_t pf_stack; uint64_t kernel_stack; Comment deleted
I guess author thinks "64 bits for systems is ought to be enough" Comment deleted
It's not about data size, but rather about storing a pointer inside a regular integer variable, which may violate pointer logic on some systems (where a pointer is not just a single number). Comment deleted
I know, and those pointers to stack memory tell that it is kernel threads which make it even more !!fun!! Comment deleted
I'm pretty sure those are handles to the stack not the stack pointer itself Comment deleted
mother_proc :D is there parent_1_proc and parent_2_proc? Comment deleted