son `parámetros de cadena const` (rosca)

Question

segura

Este código

procedure MyThreadTestA(const AStr: string); 

es más rápido que

procedure MyThreadTestB(AStr: string); 

mientras se realiza el mismo trabajo, tanto pasar un puntero.

Sin embargo, la versión B 'correctamente' actualiza la cuenta de referencia de AStr y hace una copia si la cambio.
La versión A solo pasa un puntero y solo el compilador me impide cambiar AStr.

Versión A no es seguro si no hago trucos sucios en ensamblador o de otra manera de eludir la protección del compilador, esto es bien conocido, pero ...

se pasa por referencia AStr como un const parámetros hilo de seguridad?
¿Qué sucede si el recuento de referencias de AStr en otro hilo pasa a cero y la cadena se destruye?

Answer 1

No, tales trucos no son seguros para subprocesos. Const previene el add-ref, por lo que los cambios por otro hilo afectarán el valor de maneras impredecibles. Programa de ejemplo, intenta modificar la const en la definición de P:

{$apptype console} 
uses SysUtils, Classes, SyncObjs; 

type 
    TObj = class 
    public 
    S: string; 
    end; 

    TWorker = class(TThread) 
    public 
    procedure Execute; override; 
    end; 

var 
    lock: TCriticalSection; 
    obj: TObj; 

procedure P(const x: string); 
// procedure P(x: string); 
begin 
    Writeln('P(1): x = ', x); 
    Writeln('Releasing obj'); 
    lock.Release; 
    Sleep(10); // give worker a chance to run 
    Writeln('P(2): x = ', x); 
end; 

procedure TWorker.Execute; 
begin 
    // wait until TMonitor is freed up 
    Writeln('Worker started...'); 
    lock.Acquire; 
    Writeln('worker fiddling with obj.S'); 
    obj.S := 'bar'; 
    TMonitor.Exit(obj); 
end; 

procedure Go; 
begin 
    lock := TCriticalSection.Create; 
    obj := TObj.Create; 
    obj.S := 'foo'; 
    UniqueString(obj.S); 
    lock.Acquire; 
    TWorker.Create(False); 
    Sleep(10); // give worker a chance to run and block 
    P(obj.S); 
end; 

begin 
    Go; 
end. 

Pero no se limita sólo a las discusiones; la modificación de la dirección de la variable subyacente tiene efectos similares:

{$apptype console} 
uses SysUtils, Classes, SyncObjs; 

type 
    TObj = class 
    public 
    S: string; 
    end; 

var 
    obj: TObj; 

procedure P(const x: string); 
begin 
    Writeln('P(1): x = ', x); 
    obj.S := 'bar'; 
    Writeln('P(2): x = ', x); 
end; 

procedure Go; 
begin 
    obj := TObj.Create; 
    obj.S := 'foo'; 
    UniqueString(obj.S); 
    P(obj.S); 
end; 

begin 
    Go; 
end. 

Answer 2

Para añadir a la respuesta de Barry: Es definitivamente flujos seguros si la cadena que conseguir pasado venía de una variable local dentro del ámbito que llaman.

En ese caso, esa variable local contendrá una referencia válida y la única forma (suponiendo solo un código pascal válido, sin manipular en asm) para que esa variable local sea modificada es si su llamada regresa.

Esto también incluye todos los casos donde la fuente de la variable de cadena es el resultado de una llamada de función (incluyendo acceso de propiedad, por ejemplo, TStrings.Strings []) porque en este caso el compilador tiene que almacenar la cadena en una temperatura local variable.

Los problemas de seguridad de subprocesos solo pueden producirse si está transfiriendo directamente una cadena desde una ubicación donde esa cadena puede cambiarse (por el mismo hilo u otro) antes de que regrese su llamada.