rev 7747 question: critical section enter and leave?

Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

<< < (3/4) > >>

ollydbg:

--- Quote from: thomas on February 01, 2012, 02:07:24 pm ---Well it's too late for that after you've spent many hours... but I would just have made my own locker class identical to the original wxMutexLocker with logging added in constructor and destructor, and added a #define wxMutexLocker myLoggingMutexLocker when desired. When exactly the section is entered and left is clear: enter when the locker object is created, leave when the scope ends (next closing curly brace).

--- End quote ---
The macro can have the current function and line information

--- Code: ---#define THREAD_LOCKER_ENTER(NAME) \
   CCLogger::Get()->DebugLog(F(_T("%s.Enter() : %s(), %s, %d"), \
   wxString(#NAME, wxConvUTF8).wx_str(), \
   wxString(__FUNCTION__, wxConvUTF8).wx_str(), \
   wxString(__FILE__, wxConvUTF8).wx_str(), \
   __LINE__))
   #define THREAD_LOCKER_ENTERED(NAME) \
   CCLogger::Get()->DebugLog(F(_T("%s.Entered() : %s(), %s, %d"), \
   wxString(#NAME, wxConvUTF8).wx_str(), \
   wxString(__FUNCTION__, wxConvUTF8).wx_str(), \
   wxString(__FILE__, wxConvUTF8).wx_str(), \
   __LINE__))
   #define THREAD_LOCKER_LEAVE(NAME) \
   CCLogger::Get()->DebugLog(F(_T("%s.Leave() : %s(), %s, %d"), \
   wxString(#NAME, wxConvUTF8).wx_str(), \
   wxString(__FUNCTION__, wxConvUTF8).wx_str(), \
   wxString(__FILE__, wxConvUTF8).wx_str(), \
   __LINE__))

--- End code ---
How can you reference the caller in the locker's destructor?

--- Quote ---Why are there so many locks/unlocks anyway? I counted 85 in the 3 CC files, that seems like an awful lot. I've never really touched code completion because it always scared me off... but naively thought, wouldn't one normally want to parse one complete file at a time (in N threads), and only lock/unlock the shared data structure to flush in all newly parsed tokens once after finishing each file? Something like that?

--- End quote ---

There are too many lockers(I hate them :)), because we want to access to the TokensTree from either GUI or working thread. So, we need at least a locker of the TokensTree.
The other reason is that: wxString is not thread safe(wxString is reference counted, but the counter is not thread safe, std::string is reference counted, but its counter is thread safe)

Edit:
wxWidgets 2.9.x use std::string/std::wstring internally for wxString, thus it is much safer than 2.8.x version.

MortenMacFly:

--- Quote from: thomas on February 01, 2012, 02:07:24 pm ---Why are there so many locks/unlocks anyway?

--- End quote ---
Most of them are if the tokens tree is accessed either from the parser to fill it or from the UI to obtain information.
The second most are critical sections whenever a parser changes (options or actually parses a file).

MortenMacFly:

--- Quote from: ollydbg on February 01, 2012, 02:22:03 pm ---How can you reference the caller in the locker's destructor?

--- End quote ---
A good reason for the macros, btw. ;-)

ollydbg:
The worse thing I can imagine is that:
1, we have TokensTree: TreeA and TreeB
2, we have two parserthread ThreadA and ThreadB
Now, ThreadA only accesses TreeA, ThreadB only accesses TreeB.

I once asked Loaden: why in this case, we still have a s_TokensTreeCritical to protect the access to different trees. Also Why we can't concurrently run two Parserthreads like the above case?

He explained to me that the reason is "wxString is not thread safe", this means some wxString's contents may be shared in both TreeA and TreeB, as the wxString(wx2.8.x) can not protect their reference counter in multiply threads accessing.

That's the reason that even we are in "One parser object for One cb project" mode (In this case, we have many Parser objects, and each Parser instance have its own TokensTree), we still need a static s_TokensTreeCritical.

So bad... :)

MortenMacFly:

--- Quote from: ollydbg on February 01, 2012, 02:56:56 pm ---He explained to me that the reason is "wxString is not thread safe", this means some wxString's contents may be shared in both TreeA and TreeB, as the wxString(wx2.8.x) can not protect their reference counter in multiply threads accessing.

--- End quote ---
What strings are these? Just the one in the tokens, or are there more? Why don't we simply replace them with "something" thread-safe? (One reason I could think of not so easy with something else than wxString is encoding conversion btw...)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version