[fpc-pascal] Thread Safety of String

Bruno Krayenbuhl kraybruno at bluewin.ch
Thu Jun 5 11:23:34 CEST 2014


My point of view after looking at the code.



  This code is not thread safe.



Discussion

    gtest.sflag := inttostr(gtest.nflag) ; -> will call 
fpc_AnsiStr_To_ShortStr



fpc_AnsiStr_To_ShortStr is programmed as :



procedure fpc_AnsiStr_To_ShortStr (out res: shortstring; const S2 : 
Ansistring);[Public, alias: 'FPC_ANSISTR_TO_SHORTSTR'];  compilerproc;

{

  Converts a AnsiString to a ShortString;

}

Var

  Size : SizeInt;

begin

  if S2='' then

   res:=''

  else

   begin

     Size:=Length(S2);

     If Size>high(res) then

      Size:=high(res);

     Move (S2[1],res[1],Size); // 1° ~bk Copy the string

     byte(res[0]):=byte(Size);  // 2° ~bk patch the length

   end;

end;



1° and 2° (the processor instructions generated for the task) can not be 
guaranteed to be executed in order on most processors.

+

As far as I know, or at least that would be something that I would consider 
as true, pre-emptive multitasking may switch the threads during 1° or 
between and 1° and 2°.

+

Thread doing

    if gtest.sflag = '123456' then begin // 3° ~bk unfinished 
AnsiStr_To_ShortStr ?

      // gtest.sflag is equal to '123456'



3° ~bk unfinished AnsiStr_To_ShortStr : res might contain '1234567' with 
length 6 because if contained a length of 6 before step 2°, but the length=6 
would be, for example, the residue length of the previous res= '263456' .



And so on.



My experience is that for these things one must use a CriticalSection or 
similar thread protection.



Regards, Bruno




More information about the fpc-pascal mailing list