Tecniche di blocco

0

Le librerie RAD Delphi implementano molti oggetti thread-friendly in un modo che costringe a dichiarare un altro oggetto per memorizzare il riferimento restituito dal metodo di blocco di quell'oggetto. L'oggetto quindi incapsula essenzialmente l'oggetto primo che viene restituito al momento del blocco. Ad esempio;

List := ThreadList.Unlocklist;
// do something with List
ThreadList.LockList;

Perché viene adottato questo approccio? Perché ereditare dall'oggetto primo, aggiungendo l'oggetto di blocco, sovrascrivendo costruttori e distruttori, scoraggiato? Ad esempio la seguente implementazione aggiunge un TMREWSync a un elenco;

IMREWS = interface

  ['{5B6DE5FA-847B-42D5-8BF4-9EB20A452C54}']

  procedure BeginRead;
  function  BeginWrite: Boolean;
  procedure EndRead;
  procedure EndWrite;

end;

TThreadList = class ( TList, IMREWS )
private

  FLock : TMREWSync;

public

  constructor Create;
  destructor  Destroy; override;

  property Lock : TMREWSync read FLock implements IMREWS;

end;

constructor TThreadList.Create;
begin
  FLock := TMREWSync.Create;
  inherited;
end;

destructor TThreadList.Destroy;
begin
  inherited;
  FLock.Free;
end;

// Usage:

ThreadList.BeginWrite;
// Do something with ThreadList
ThreadList.EndWrite;
    
posta Umair Ahmed 03.03.2014 - 13:32
fonte

2 risposte

1

quando si eredita cadi nella trappola load-modify-store

di voler aumentare la priorità di un oggetto:

int prio = myObject.getPriority();
myObject.setPriority(prio+1);

ora considera cosa succede quando un altro thread vuole abbassare la priorità:

int prio = myObject.getPriority();
myObject.setPriority(prio-1);

una sequenza interlacciata di chiamate potrebbe essere:

//thread1         //thead2
int prio1 = myObject.getPriority();
                  int prio2 = myObject.getPriority();
myObject.setPriority(prio1+1); // now is prio+1
                  myObject.setPriority(prio2-1); now is 2 lower than expected

ci sono molte altre opzioni che sono quasi tutte cattive

questo può essere risolto incapsulando l'operazione in un metodo ma che diventa rapidamente non fattibile per operazioni complesse che coinvolgono più oggetti

Inoltre, se l'oggetto cambia, è necessario modificare la sottoclasse di blocco per includere i nuovi metodi

    
risposta data 03.03.2014 - 13:41
fonte
1

Un motivo ineludibile per adottare questo approccio è perché un oggetto ha un lucchetto invece che un lucchetto. Appena si ottiene è un / ha un corretto, tutto diventa più semplice.

    
risposta data 03.03.2014 - 14:16
fonte

Leggi altre domande sui tag