parser test rev 7157 error?

[oBFusCATed]

ollydbg: on some OSes mutexes could be recursive.
You can do

Code

mutex.lock();
some code
mutex.lock();

some code
mutex.unlock();
mutex.unclock();

This is not recommended, but it is possible. (http://docs.wxwidgets.org/stable/wx_wxmutex.html#wxmutex)

[ollydbg]

ollydbg: on some OSes mutexes could be recursive.
You can do

Code

mutex.lock();
some code
mutex.lock();

some code
mutex.unlock();
mutex.unclock();

This is not recommended, but it is possible. (http://docs.wxwidgets.org/stable/wx_wxmutex.html#wxmutex)

Hi, thanks for the great explanation, I will look into it. I used to know that a critical section can only entered once.

[ollydbg]

I'm removed the locker in my local commit (git-svn).
And commit them on tonight.

I see your latest commit.
As obf said, if the locker can entered several times, it can NOT "lock" any thing. , so they can be removed.

[Loaden]

I'm removed the locker in my local commit (git-svn).
And commit them on tonight.

I see your latest commit.
As obf said, if the locker can entered several times, it can NOT "lock" any thing. , so they can be removed.

But after remove the locker, there should have some issue.
i.g. When do CC search for call tips, and another batch parse is running.
Then, there is not thread safe.
In some where, we shoud add a locker.
But now, I have no idea.

[ollydbg]

CC search for tip should only works when there is NO batch parsing.
Are there any state variable indicate that batch parsing is running?

[Loaden]

CC search for tip should only works when there is NO batch parsing.
Are there any state variable indicate that batch parsing is running?

You can open the CB workspace, and open some project, then worked on first batch parsing project.
You will catch the case.

You can do call tip search, or other local buffer parsing, but another (one or many) is still running.
If any one have good idea, pls let's me know.

[ollydbg]

@loaden, if a workspace contains many projects, and you use only ONE TokensTree for all the cbps, this could be a big issue.

Because the TokensTree is the only resource we should take care.
Every Token collected from the batch parsing was recorded in this TokensTree. So, even some projects are already parsed, there are still projects remaining working and adding Tokens to TokensTree. In the mean while, if you do some search algorithm on the TokensTree, there may be some access conflict.

[oBFusCATed]

Just to note:
The general principals:
1. Shared state/resource should be protected, so only one thread could access it.
2. Protecting (locking) the share state/resource should be done for minimal periods of time. To implement this most of a time something like this can be used:

Code

// do some processing on a temp var;
MySharedResource temp;
temp.process();
mutex.lock()
shared.swap(temp);
mutex.unlock();

3. Using hacks == pain! Don't do it!

You need to identify the shared state and protect it in the best possible way!

[Loaden]

@loaden, if a workspace contains many projects, and you use only ONE TokensTree for all the cbps, this could be a big issue.

No, In current use one parser per one TokensTree.
But there still exist thread-safe issue.
Include the symbols browser.

[Loaden]

Just to note:
The general principals:
1. Shared state/resource should be protected, so only one thread could access it.
2. Protecting (locking) the share state/resource should be done for minimal periods of time. To implement this most of a time something like this can be used:
3. Using hacks == pain! Don't do it!

You need to identify the shared state and protect it in the best possible way!

Thanks, I know that, but I can't find another place need protected again.
oBFusCATed , If you have some time, could you help me check the Parser of CC?

[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();
}

[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:

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.

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:

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.

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