critical-section

Is it possible to disable all interrupts with a ASM/C/C++ program to get full control about the processor? If yes -> how? If not -> how do "atomic" operation system calls work (for example entering a critical section)? Thanks for your help! Ludwig Weinzierl In x86 assembly the the commands are sti set interrupt enable bit cli clear interrupt enable bit These commands set and clear the IF Flag . When the IF flag is set, the CPU will handle hardware interrupts, and when it is clear the CPU will ignore hardware interrupts. It does not affect the handling of non-maskable interrupts though, nor

I was debugging a multi-threaded application and found the internal structure of CRITICAL_SECTION . I found data member LockSemaphore of CRITICAL_SECTION an interesting one. It looks like LockSemaphore is an auto-reset event (not a semaphore as the name suggests) and operating system creates this event silently when first time a thread waits on Critcal Section which is locked by some other thread. Now, I am wondering is Critical Section always faster? Event is a kernel object and each Critical section object is associated with event object then how Critical Section can be faster compared to

Does having 2 different threads : one reading from a C# array (e.g from first location), and another one writing to the same C# array but to a different location(e.g to the last location) is thread safe or not? (And I mean here without locking reading nor writing) This particular case is safe, yes. Reading and writing to different parts of an array does not interfere with the other operations. However, reading and writing to the same location can give you problems, depending on the type of element, and the size of the elements. I'm not sure this is guaranteed to be safe. Imagine you have byte[

On a multi-threaded Linux application I use a mutex for critical sections. This works very well except for the fairness issue. It can happen that a thread leaving a critical section and re-entering right away does not give any other thread a chance. For example while(true) { critsect.enter(); ... do calculations ... ... maybe call a blocking operation so we sleep ... critsect.leave(); } might very likely stop any other thread to enter the same critical section. Mutexe are not fair. Is there a solution to making a fair critical section? I was thinking of adding a queue so that critical sections

Suppose we have a shared queue (implemented using an array), which two threads can access, one for reading data from it, and other for writing data to it. Now, I have a problem of synchronization. I'm implementing this using Win32 API's (EnterCriticalSection etc.). But my curiosity is what will be the critical section code in enqueue and dequeue operations of the queue? Just because, two threads are using a shared resource? Why I'm not able to see any problem is this: front and rear are maintained, so, when ReaderThread reads, it can read from front end and when WriterThread writes, it can

I have to implement a read/write lock in C++ using the Win32 api as part of a project at work. All of the existing solutions use kernel objects (semaphores and mutexes) that require a context switch during execution. This is far too slow for my application. I would like implement one using only critical sections, if possible. The lock does not have to be process safe, only threadsafe. Any ideas on how to go about this? I don't think this can be done without using at least one kernel-level object (Mutex or Semaphore), because you need the help of the kernel to make the calling process block

In Windows environment, is Boost's scoped mutex using WinAPI's critical sections, or something else? The current version of boost::mutex uses neither a Win32 CRITICAL_SECTION , nor a Win32 Mutex. Instead, it uses atomic operations and a Win32 Event for blocking waits. Older versions (boost 1.34.1 and prior) were a wrapper around CRITICAL_SECTION on Windows. Incidentally, the mutex itself is not scoped. The boost::mutex::scoped_lock type and, in recent versions, boost::lock_guard<boost::mutex> and boost::unique_lock<boost::mutex> provide RAII wrappers for locking a mutex to ensure you don't

This is from MSDN: The lock keyword ensures that one thread does not enter a critical section of code while another thread is in the critical section . Does a critical section have to be same as the critical section ? Or does it mean: The lock keyword ensures that one thread does not enter any critical section guarded by an object of code while another thread is in any critical section guarded by the same object . ? class Program { static void Main(string[] args) { TestDifferentCriticalSections(); Console.ReadLine(); } private static void TestDifferentCriticalSections() { Test lo = new Test();