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

parser test rev 7157 error?

<< < (6/7) > >>

Loaden:
And I personal think all the random crash related about thread-safe issue.
I can't find a best way to handle thread-safe issue. :(

oBFusCATed:
No, no time at the moment, unfortunately.
Another general strategy is to start with one big lock, which does good protection, but makes performance to suffer and then later split this lock in many smaller locks.

Something like:


--- Code: ---MyParser::Parse()
{
   lock();
   all the parsing code();
   unlock();
}

MyCC::DoCompletion()
{
   lock(); // this could use timeout and return if it expires
   gather completion info
   unlock();
}

--- End code ---

ollydbg:
I was aware that we use "critical section" in cc, not mutex.
I thing generally, critical section is only allowed ONE entry.
From the document:
http://docs.wxwidgets.org/stable/wx_wxcriticalsectionlocker.html
a critical section locker is just enter the section on its constructor, and leave the section in its destructor.
So, I still get puzzled what why they can still re-entry.

As morten said:

--- Quote ---Your example is OK. The implementation of ParserTest provides the global variable "g_ParserCritical". As ParserTest is intatiated several times (inspect the addresses in your debug - they differ) the locker is also created multiple times. And that is OK, because the lock shall apply just the one object itself.
--- End quote ---
As a locker is created, this means it will enter the critical section on its constructor. This means the same critical section entered several times. why?

oBFusCATed:
Ollydbg: you're messing the concepts :)

There is wxMutex and wxMutexLocker... wxMutexLocker is to have a RAII style locking/unlocking. wxMutex is the real synchronization object.
Same is for wxCriticalSection and wxCriticalSectionLocker.

You can read about RAII here: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

ollydbg:
Hi, OBF, thanks for your help.
In-fact, I know RAII mechanism.

Now, I can solve my puzzle by reading this page:
Critical Section Objects (Windows)

and look:

--- Quote ---When a thread owns a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. To release its ownership, the thread must call LeaveCriticalSection one time for each time that it entered the critical section. There is no guarantee about the order in which waiting threads will acquire ownership of the critical section.

--- End quote ---

That is to say: In the same thread, one critical section can be re-entry. , :D, so a critical section is only try to lock ANOTHER thread, not the one itself.

Navigation

[0] Message Index

[#] Next page

[*] Previous page