Maybe your parallelization strategy for this specific loop is causing cache misses. Try redesigning the loop and see if you can improve cache hits. Its very important to test several variations of the critical loop. Also test both shared and privatization clauses on some variables, you may get better performance through selective privatization. Keep in mind not all nested loops benefit from parallelization. Best Wishes, -David Delaune

tks; i'm looking into it

Thanks, u'r absolutely right about the pitch. sorry that my code is ugly that way (the "j" index came before the "i" somehow). but i think i've tried what you've suggested: for (int line_no=0; line_no<100; line_no++) for (int column_no=0; column_no<100; column_no++) *(pbdata+line_no*Pitch+2*column_no+1) = 0xF8; Do I understand what you mean, or am i missing something? You say the bug is not locking the whole surface memory? in desperation i've tried to access bytes seemingly outside my surface (like: line_no = 120); to my surprise nothing crashed (as if i've accessed something legal), but the app seemed to be in a deadlock (so maybe it was not locked)