Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Precompiled headers (PCH) support in Code::Blocks

<< < (4/8) > >>

Urxae:

--- Quote from: mandrav on October 19, 2005, 05:25:09 pm ---
--- Quote ---I'd advise to at least take some kind if command-line switch to turn using the precompiled header on/off. Maybe just put a big #ifdef CB_PRECOMP around the contents of the precompile #includes (if you haven't done this already that is).
--- End quote ---

Actually, CB_PRECOMP is used :)

--- End quote ---

Ah, good. I had no way to check as it doesn't seem to have propagated to anonymous CVS yet :(.

rickg22:
Hmmmmmmmmmmm.... argh. Well, good luck, I guess that's all I can do...

Or maybe... does it deadlock with the "enhanced stability" on? If that's the case it could be a recursive wxYield problem. (I mention this because i haven't experienced such deadlocks in my config...)

is there any way to set or release a mutex checking the current thread #? So it won't try to lock a mutex twice in the same thread?

mandrav:
What would be the point? Mutexes are used for isolating access to one thread at a time  :shock:

rickg22:
Yes but I wondered if the hang was caused by a mutex being locked twice in the same thread.
Anyway is the error you talk about the same than the one reported here? http://forums.codeblocks.org/index.php/topic,1051.0.html

Erm, I better shut up, this thread is going out of topic.

thomas:
Is it possible that this freeze is due to a screwed config file or something, completely unrelated to threads and mutexes?

After working with HEAD for a while now, I switched back to RC1-1 which I normally used for development (don't feel comfortable developing on a cvs version for some reason), and guess what....
I experienced the Rick syndrome twice within one hour. I never had it before.
So if that was not mere coincidence, the formerly stable release caught the pestilence from the afflicted one, or it is unrelated to the actual executable...  (or, I dread to think... it's been broken all the time, but nobody noticed before).

Rick:
Linux pthreads check for double locking (if requested), but Windows does not, this is explicitely documented on MSDN. So since wxWindows must take the least common denominator... :(

What might work for your idea, though, is something like this:


--- Code: ---static size_t LockingThreadID;

if(lockingTID == GetThreadID())
  return; // or whatever, just don't get the lock
mutex.Lock();
lockingTID = GetThreadID();
...
do something that needs to be protected ...
...
lockingTID = 0; // don't call wxYield now...
mutex.UnLock();
// now do what you want

--- End code ---

This tampering with the thread id variable is obviously not thread safe as such, but hey, we aren't interested in that! We are interested to prevent the same thread from entering again. A different thread will block acquiring the lock, fair enough. And the same thread coming back through a recursive wxYield will never try to get the lock.
The only important thing is not to have anything that might call wxYield after resetting the thread id variable to zero, obviously.

Navigation

[0] Message Index

[#] Next page

[*] Previous page