---
title: "multithreading"
source: https://www.jemoka.com/posts/kbhmultithreading/
---

we can have concurrency within a single process&mdash;each running a single function We will solve problems:
never race condition never deadlock thread you can spawn a thread using the thread() can even pass function parameters threads share all virtual address space: bugs can arise when multiple threads modify the same thing at the same time&mdash;each thread has access to a small chunk of the stack threads are actually the unit of concurrency: the OS actually chooses threads to run // now the thread can execute at any time: once a thread is made, it will run in any order thread myThread(function_to_run, arg1, arg2, ...); // threads run AS SOON AS SPAWENED: so We can wait for a thread:
myThread.join() You can also start a bunch on a loop:
thread threads[3]; for (thread&amp; cf : threads) { cf = thread(func, ...); } Importantly, unlike waitpid, we can&rsquo;t join an arbitrary thread. We basically have to wait for all your threads to finish.
DEBUGGING TRICK: adding a sleep call everywhere shouldn&rsquo;t cause any problems; if it does, there&rsquo;s a race condition.
passing by reference threading doesn&rsquo;t know the type of arguments being passed into a function; this is especially prevalent when passing by reference.
static void mythingref(int &amp;pbr); thread(myfunc, ref(myint)); Remember: ref will SHARE MEMORY, and you have no control over when the thread runs. So once a pointer is passed all bets are off in terms of what values things take on.
processes vs threads Processes Threads isolate virtual address spaces shares virtual address space to share info can run external programs can&rsquo;t run external programs (execvp wipes) harder to coordinate tasks within the same program easier to coordinate tasks within a program threads are really the main way to break down big tasks.
race condition undesirable behavior caused by arbitrary execution order. we typically solve them using mutexes.
thread safe thread safe functions are ones whereby its designed to prevent against unexpected behavior during threading.
we want atomicity in the code: we want entire data viewing + modification operations to not be interrupted&mdash;otherwise, you will generate race conditions.
Recall: C++ statements themselves are not INHERENTLY autonomic.
we want to outline a &ldquo;critical section&rdquo; and ensure it doesn&rsquo;t get ran more than once.
critical section A critical section is a region of code which should only be executed by one thread at a time. We want to keep this section as small as possible to preserve performance.
we want to organize it to be as small as we possibly can we want to move the critical section in terms of expressions; so if you have a loop you should put the loop in the outer area, and do the checking + break within if our critical sections are not small, we would have little benefits to multithreading
mutex it would be nice if a critical section can only be executed once; a mutex can be shared across threads, but can only be &ldquo;owned&rdquo; by a single thread at once.
mutex tmp; tmp.lock(); tmp.unlock(); importantly, if multiple threads are waiting on a mutex, the next thread that&rsquo;s going to get the mutex
when there are multiple threads writing to a value when there is a thread writing and one or more threads reading if you are no writes, you don&rsquo;t need a mutex when dealing with mutex, beware of deadlock
Sleep call can happen by putting a sleep call in certain places.
implementation Things it needs to do:
track whether or not the mutex is locked/unlocked track which thread is the owner of the lock threads that want to get this lock int locked = 0; Queue blocked_queue; void Lock::Lock() { // disable interrupts: otherwise multiple threads // could come and lock the mutex (such as between // the locked check and lock =1 IntrGuard grd; if (!locked) { // if our thread is not locked, just lock it locked = 1; } else { // if our thread is locked, we need to prevent our current // thread from going to the ready queue, and push it to the current thread blocked_queue.push(CURRENT_THREAD); // remember this isn&#39;t an issue even if IntrGuard // didn&#39;t yet go out of scope; because it will either // land on a context_switch which will enable interrupts for you // or land on the beginning of a threadfunc helper, which // is also going to enable interrupts for you // nicely, the interrupts are here are *off* as required because switching // to another thread always will result in reenabling (either by new thread, // by timer handler, or by IntrGuard) mark_block_and_call_schedule(CURRENT_THREAD); } } void Lock::Unlock() { // disable interrupts: otherwise multiple threads // could come and lock the mutex (such as between // the locked check and lock =1 IntrGuard grd; // if our thread is locked and nobody is waiting for it if (q.empty()) { locked = 0; } else { unblock_thread(q.pop()); // we do not switch to the unblocked thread, just add it to the // ready queue. we are entrusting the scheduler to start this thread // whenever we feel right } } IntrGuard IntrGuard will turn off interrupts for the duration of its scope; when it goes out of scope, it will restore the state of the interrupt before (whether on or off). So, implementing the mutex code above without InterGuard:
int locked = 0; Queue blocked_queue; void Lock::Lock() { // disable interrupts: otherwise multiple threads // could come and lock the mutex (such as between // the locked check and lock =1 bool interrupsEnabled = intr_enabled(); // only disable interrupts if they are currently // on if (interrupsEnabled) { intr_enable(false); } if (!locked) { // if our thread is not locked, just lock it locked = 1; } else { // if our thread is locked, we need to prevent our current // thread from going to the ready queue, and push it to the current thread blocked_queue.push(CURRENT_THREAD); mark_block_and_call_schedule(CURRENT_THREAD); } // if interrupts was on, turn them on again. // otherwise, do nothing if (interrupsEnabled) { intr_enable(true); } } void Lock::Unlock() { // disable interrupts: otherwise multiple threads // could come and lock the mutex (such as between // the locked check and lock =1 bool interrupsEnabled = intr_enabled(); // only disable interrupts if they are currently // on if (interrupsEnabled) { intr_enable(false); } // if our thread is locked and nobody is waiting for it if (q.empty()) { locked = 0; } else { unblock_thread(q.pop()); // we do not switch to the unblocked thread, just add it to the // ready queue. we are entrusting the scheduler to start this thread // whenever we feel right } if (interrupsEnabled) { intr_enable(true); } }
