spinlock

I created 2 Linux kernel threads in my loadable module and I bind them to separate CPU cores running on a dual core Android device. After I run this few times, I noticed that the device reboots with a HW watchdog timer reset. I hit the issue consistently. What could be causing the deadlock? Basically, what i need to do is, make sure both the threads run do_something() at the same time on different cores without anybody stealing the cpu cycles(i.e. interrupts are disabled). I am using a spinlock and a volatile variable for this. I also have a semaphore for parent thread to wait on child thread.

While learning Java 9 I came across a new method of Thread class, called onSpinWait​ . According to javadocs, this method is used for this: Indicates that the caller is momentarily unable to progress, until the occurrence of one or more actions on the part of other activities. Can someone help me understand this method giving a real-life example? It's the same (and probably compiles to) as the x86 opcode PAUSE and equivalent the Win32 macro YieldProcessor , GCC's __mm_pause() and the C# method Thread.SpinWait It's a very weakened form of yielding: it tells your CPU that you are in a loop that

I'm trying to implement a spinlock in my code but the spinlock that I implemented based on Wikipedia results in extremely slow performance. int lockValue = 0; void lock() { __asm__("loop: \n\t" "movl $1, %eax \n\t" "xchg %eax, lockValue \n\t" "test %eax, %eax \n\t" "jnz loop"); } Is there any way of improving this to make it faster? Thanks. How about something like this (I understand this is the KeAcquireSpinLock implementation). My at&t assembly is weak unfortunately. spin_lock: rep; nop test lockValue, 1 jnz spin_lock lock bts lockValue jc spin_lock "movl $1,%%edx \n\t" // edx = 1; ".set

I am new to Linux and am reading Linux device drivers book by Rubini & Corbet. I am confused at one statement related to spinlocks ; the book states If a nonpreemptive uniprocessor system ever went into a spin on a lock, it would spin forever; no other thread would ever be able to obtain the CPU to release the lock. For this reason, spinlock operations on uniprocessor systems without preemption enabled are optimized to do nothing, with the exception of the ones that change the IRQ masking status. Further the book states The kernel preemption case is handled by the spinlock code itself. Any

Consider the following spin_lock() implementation, originally from this answer : void spin_lock(volatile bool* lock) { for (;;) { // inserts an acquire memory barrier and a compiler barrier if (!__atomic_test_and_set(lock, __ATOMIC_ACQUIRE)) return; while (*lock) // no barriers; is it OK? cpu_relax(); } } What I already know: volatile prevents compiler from optimizing out *lock re-read on each iteration of the while loop; volatile inserts neither memory nor compiler barriers ; such an implementation actually works in GCC for x86 (e.g. in Linux kernel) and some other architectures; at least one