MultiCore issues

[arthurprs]

hy guys i'm getting really beautifull problems here, program crash on dual core processors (or quad...) :lol:

i already spotted the problematic code and
im trying to use Critical_Section, but i'm not sure if i have to encapsulate ALL variables with it (even integers?)

someone can give me some tips?

ps: any article or text

[Memphis]

how do you mean include them all ?

a critical section is used for blocking threads from accessing multithreaded objects... basically objects you will write to and read from, however it depends on you use the var for example a stringlist

for i := 0 to 3000 do [....]

using a critical section here is a good idea if 1 thread may delete an object which will give u an access violation... however if you just read from the list and dont change data, then there is no point using a critical section on that part of the code...

also try to use more then 1 critical section for different parts of your code / function....

so for example....

not good:
[pascal]
EnterCriticalSection(cs);
for i := 1 to 1000 do
Check(mystrllist[i]);

for i := 1 to 100 do
Check(anotherlist[i]);
LeaveCriticalSection(cs);
[/pascal]

better:
[pascal]
EnterCriticalSection(cs_a);
for i := 1 to 1000 do
Check(mystrllist[i]);
LeaveCriticalSection(cs_a);

EnterCriticalSection(cs_b);
for i := 1 to 100 do
Check(anotherlist[i]);
LeaveCriticalSection(cs_b);
[/pascal]

didnt quite understand what you meant, but hopefully this helps. if not let me know.

-Meka][Meka

[arthurprs]

thats not what im in doubt, i know that i have to use a differents CS,

the problem is,

is Cardinal and String ThreadFree?

[AthenaOfDelphi]

Whether or not you have to protect all variables with critical sections (or things like TMultiReadExclusiveWriteSynchronizer) depends on what they are used for and how they are accessed, and the affect that changing them could have.

For example, consider this...

[pascal]
if (x>=0) and (x<items.count) then
begin
// x is changed here by a.n.other thread
myItem:=items[x];
end;
[/pascal]

Here, you are only reading X, but if X is changed by another thread where I've indicated to say -1, the next line in this thread will go boom.

You need to give careful consideration to cross thread storage and control mechanisms BEFORE you start seriously coding. One major tip is to define in advance all the critical sections you are going to use and define an order in which you will enter them and leave (the reverse of entering)... then once you've defined it, stick to it rigidly. That way, you can reduce the chances of deadlock.

[AthenaOfDelphi]

I've just realised there is another interpretation of your question...

You could be talking about having one critical section per variable

If so, the answer is no... don't do it... the overheads would be massive. Think logically about your data and protect the variables in logical blocks.

And now, I've just re-read your last post... DOH!! I should read more carefully before I fire up my keys.... in short... any data storage mechanism within Delphi cannot (and should not) be considered thread safe except perhaps TThreadList (I think thats what it's called). If its likely to be accessed (by that I mean read and simultaneously written to) by multiple threads, then it will need protection... either its own or a larger logical group.

[JSoftware]

operations on a cardinal are threadsafe. Operations on strings are not threadsafe. Operations on pchar's are sometimes threadsafe..

This has to do with atomicity. Cardinals are 32bit and can be contained in a cpu register. All math operations on 32 bit integers are atomic, except for more advanced operations such as sqrt, ln, etc.

Atomic operations mean that you can be sure that nothing will blow up. This means that you cannot consider memory operations(where you typecast a pointer to a simple type(pbyte, pword, pcardinal, etc)) atomic by default. Also, most operations on complex types such as records typically aren't threadsafe either.

[arthurprs]

Whether or not you have to protect all variables with critical sections (or things like TMultiReadExclusiveWriteSynchronizer) depends on what they are used for and how they are accessed, and the affect that changing them could have.

For example, consider this...

[pascal]
if (x>=0) and (x<items.count) then
begin
// x is changed here by a.n.other thread
myItem:=items[x];
end;
[/pascal]

Here, you are only reading X, but if X is changed by another thread where I've indicated to say -1, the next line in this thread will go boom.

You need to give careful consideration to cross thread storage and control mechanisms BEFORE you start seriously coding. One major tip is to define in advance all the critical sections you are going to use and define an order in which you will enter them and leave (the reverse of entering)... then once you've defined it, stick to it rigidly. That way, you can reduce the chances of deadlock.

=/ thats bad, i will have to make some functions insted of getting from the variable

are you sure that even integers and strings have to be encapsulated by CS's ?

[Memphis]

are you sure that even integers and strings have to be encapsulated by CS's ?

again that all depends on what operations you are performing on the ints and strings....

read AthenaOfDelphi's first post carefully.

[arthurprs]

are you sure that even integers and strings have to be encapsulated by CS's ?

again that all depends on what operations you are performing on the ints and strings....

read AthenaOfDelphi's first post carefully.

Inc() and Dec() on the cardinals

and simple assignment := on strings

[Mirage]

Operations should be protected by critical sections (or other means) only if there is a chance of simultaneous access to the variable from different threads. So if one thread perforns Inc(a), and other Inc(b), you don't have to protect anything. But if the both threads performs Inc(a), you should protect the corresponding code. Type of a and b doesn't matter.