critical-section

I have the following piece of code in thread A, which blocks using pthread_cond_wait() pthread_mutex_lock(&my_lock); if ( false == testCondition ) pthread_cond_wait(&my_wait,&my_lock); pthread_mutex_unlock(&my_lock); I have the following piece of code in thread B, which signals thread A pthread_mutex_lock(&my_lock); testCondition = true; pthread_cond_signal(&my_wait); pthread_mutex_unlock(&my_lock); Provided there are no other threads, would it make any difference if pthread_cond_signal(&my_wait) is moved out of the critical section block as shown below ? pthread_mutex_lock(&my_lock);

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. Kirill Kobelev No, it cannot. Documented APIs do not mention this in any way. Windows critical sections always accept recursive access. A Critical Section always allows recursion within a thread. So does a Mutex. That is by design and cannot be changed. A Semaphore, on the other hand, can prevent recursion within a

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 actually has any shared data or not right? Also during that time other threads also cannot enter part 2

I have a list wrapper that maintains two Tstringlists and a TClassList I need this to be thread safe, such that: Concurrent writes are not allowed (wait state of some sort should be entered) Reading while writing (or vice versa) is not allowed (wait state of some sort should be entered) Concurrent reads are allowed Any ideas on how I can do this? My instinct tells me it needs more than just a critical section, perhaps a semaphore or "usage counter", perhaps one of these in conjunction with a CS. I'm just not quite sure where to start - anything from an overall approach in english to psuedo

I am experienced in implementing critical sections on the AVR family of processors, where all you do is disable interrupts (with a memory barrier of course), do the critical operation, and then reenable interrupts: void my_critical_function() { cli(); //Disable interrupts // Mission critical code here sei(); //Enable interrupts } Now my question is this: Does this simple method apply to the ARM architecture of processor as well? I have heard things about the processor doing lookahead on the instructions, and other black magic, and was wondering primarily if these types of things could be

For my cross-platform application I have started to use Boost, but I can't understand how I can implement code to reproduce behavior of Win32's critical section or .Net's lock . I want to write a method Foo that can be called from different threads to control write operations to shared fields. Recursive calls within the same thread should be allowed (Foo() -> Foo()). In C# this implementation is very simple: object _synch = new object(); void Foo() { lock (_synch) // one thread can't be lock by him self, but another threads must wait untill { // do some works if (...) { Foo(); } } } Alexander

Is there any circumstance in which the LockCount field of a RTL_CRITICAL_SECTION structure in Windows can legitimately be negative? We're tracking a VERY elusive crash and one symptom we're seeing is a CS with a negative LockCount. At the time of the crash, the count is -6, but it seems to routinely be -1, -2, etc. Before go chasing off after that on the assumption that it is a Very Bad Thing for this to occur, I just want to verify that that assumption is correct. I can find little to no information on the inner workings of RTL_CRITICAL_SECTION. Negative lock count is normal behaviour on some

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 quite familiar with FastMM et al) - memory usage was monitored with Process Explorer; both Virtual