critical-section

问题 By default, a CRITICAL_SECTION object is recursive. Can this behaviour be configured like a pthread mutex to enable or disable recursive thread access? To clarify in response to the comments: I am referring specifically to a Windows CRITICAL_SECTION object, not a Windows mutex. 回答1: No, it cannot. Documented APIs do not mention this in any way. Windows critical sections always accept recursive access. 回答2: A Critical Section always allows recursion within a thread. So does a Mutex. That is by

问题 Just want a little clarity on the this. Imagine I use the windows api of EnterCriticalSection. I call all of them with EnterCriticalSection(&criticalsection); This is the thread function that is multi threaded void thread (){ //enter critical section (part 1) data //leave critical section ///more data 1 //entercritical section (part 2) //more data 2 //leave critical section } Once a thread enters the critical (part 1), other threads cannot enter that section regardless of whether more data 1

问题 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

问题 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? 回答1: I don't think this can be done without using at least one kernel

问题 We have a D2007 application whose memory footprint grows steadily when running on Windows Server 2008 (x64, sp1). It behaves normally on Windows Server 2003 (x32 or x64), XP, etc... where it goes up and down as expected. We have tried with the included Memory Manager or the latest FastMM4 4.92 with the same results. Has anyone tried to monitor the memory usage of any Delphi app on Win2008 and would confirm? Or would have any clue? Precisions: - no memory leaks in the common sense (and yes I'm

问题 What's the best equivalent? I didn't find any reasonable solution for such a simple function. Choices I'm aware of: 1) MPEnterCriticalRegion - this is unfortunately extremely ineffective, probably because despite it's name it enters kernel mode, so for repeating locks it just takes way too much time... 2) OSSpinLockLock - unusable, because apparently not recursive. If it would be recursive, it would be the correct equivalent. 3) pthread_mutex_lock - didn't try, but I don't expect much,

问题 This is the problem I have: I'm using Python 2.7, and I have a code which runs in a thread, which has a critical region that only one thread should execute at the time. That code currently has no mutex mechanisms, so I wanted to inquire what I could use for my specific use case, which involves "dropping" of "queued" functions. I've tried to simulate that behavior with the following minimal working example: useThreading=False # True if useThreading: from threading import Thread, Lock else:

问题 I'm trying to set spin count for CRITICAL_SECTION to zero by different methods: int main() { CRITICAL_SECTION cs; ::InitializeCriticalSection(&cs); printf("Spin count by default %08X\n", cs.SpinCount); ::DeleteCriticalSection(&cs); ::InitializeCriticalSectionAndSpinCount(&cs, 0); printf("Spin count with zero spin count init %08X\n", cs.SpinCount ); ::DeleteCriticalSection(&cs); ::InitializeCriticalSectionEx(&cs, 0, 0); printf("Spin count with zero spin count and flags init %08X\n", cs

问题 What way is better and faster to create a critical section? With a binary semaphore, between sem_wait and sem_post. Or with atomic operations: #include <sched.h> void critical_code(){ static volatile bool lock = false; //Enter critical section while ( !__sync_bool_compare_and_swap (&lock, false, true ) ){ sched_yield(); } //... //Leave critical section lock = false; } 回答1: Regardless of what method you use, the worst performance problem with your code has nothing to do with what type of lock

问题 We have some data structures that we are sharing across processes on Windows. (Via a shared data segment in a DLL that's loaded by all these processes.) We need to synchronize some accesses and we measured that the performance hit of using a Win32 Mutex is too costly. CRITICAL_SECTION cannot be put into shared memory due to some of it's advanced features. This leaves us with the requirement of a simple locking/mutex solution based directly on the Interlocked* family of function on Win32.