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

using memory pool for the SearchTree Node

<< < (2/4) > >>

ollydbg:
@Jens:

I will test it again. ( I think every test would be run after a system reboot :()
The last test, I just compare the "official nightly build" with my own build version( which as many code changes in CC).

I have exam the code carefully, when a parserThread need to add a Token, it would be protect by a Mux. The Core code was in:


--- Code: ---int TokensTree::AddToken(Token* newToken,int forceidx)
{
    ...
    size_t idx2 = m_Tree.AddItem(name,tmp_tokens,false);// this will add a now item to "TokenSearchTree"
    ...
}

--- End code ---

I will give the report then.

Edit
By the way, I only have Windows XP at hand.
Forget to say: thanks for your test!

thomas:

--- Quote from: ollydbg on July 04, 2009, 11:40:06 am ---Ok, I find some code that can confirm it is quite "SAFE", When adding a Token, it use a s_MutexProtection. In the parsing thread.
--- End quote ---
That's an example of what happens if you fix things that you've not understood, and it's one of the reasons I'm not touching anything related to CC again :)

The major reason, apart from cache locality of data and reduced fragmentation, to implement the block allocator was, long long ago, to avoid the heap lock (and, the bucket search), which was fine because there was only one thread using these objects.
Then, threads were added, which led to occasional weird behaviour that nobody could understand (and some very rare crashes that were not related to the block allocator).
Throwing threads at the beast made explicit locking necessary, so the net gain was exactly zero. On top of that the (misnomed) mutex has at least 4 global definitions in different compilation units, which somewhat defeats its purpose as a lock :)

thomas:
In case you wonder what I'm talking about, try this:

foo.h
--- Code: ---#include <cstdio>

static int xxx;

void foo();
void p1();

--- End code ---
foo.cpp
--- Code: ---#include "foo.h"

void foo() { xxx = 5; }
void p1()  { printf("%d\n", xxx); }
--- End code ---
main.cpp
--- Code: ---#include "foo.h"

void p2() { printf("%d\n", xxx); }

int main()
{
    xxx = 1;
    foo();

    p1();
    p2();

    return 0;
}

--- End code ---


Now, in your head, replace "int" with "wxCriticalSection" and "foo.h" with "token.h". Surprise.

ollydbg:

--- Quote ---Now, in your head, replace "int" with "wxCriticalSection" and "foo.h" with "token.h". Surprise.

--- End quote ---
@thomas
I can understand your meaning. It's quite strange this variable was defined in header file, and use as a static decoration.

I should read more...... That's your signature "Never fix a bug you don’t understand"  :D

Thanks.

Edit


--- Quote ---On top of that the (misnomed) mutex has at least 4 global definitions in different compilation units, which somewhat defeats its purpose as a lock
--- End quote ---

the token.h was included in these compilation units:

token.cpp
parser.cpp
parserthread.cpp
nativeparser.cpp

I guess the reason of using this kind of mux is that they only want to  lock the operation in it's own compilation units :D Not operation between different units.

thomas:

--- Quote from: ollydbg on July 04, 2009, 03:21:24 pm ---I guess the reason of using this kind of mux is that they only want to  lock the operation in it's own compilation units :D Not operation between different units.
--- End quote ---
To be honest, I don't think this was intentional at all, it just incidentially happens to work without crashing  :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page