W1000 Symbol 'Resume' ist veraltet ????

[EWeiss]

Zitat:

Statt .Resume nutzt man jetzt .Start
und .Suspend gibt es nicht mehr ... auch keinen Ersatz dafür.

Danke.. Ja das habe ich gelesen.
Geben tut es das schon noch man soll es halt möglichst nicht mehr verwenden.

Einen Ansatz einer möglichen Lösung hat Tryer ja schon gepostet (danke)
Prüfe gerade ob man es für jede auftretende Sitution verwenden kann.

PS:
Das mit Suspend erklärt vielleicht meine sporadisch auftretenden hänger
wenn ich von einem zum anderen Plugin schalte.

Edit:
Also das mit Start kannst auch vergessen auch kein ersatz für Resume.

Zitat:

Erste Gelegenheit für Exception bei $7597B9BC. Exception-Klasse EThread mit Meldung 'Start kann für einen laufenden oder unterbrochenen Thread nicht aufgerufen werden'. Prozess Example.exe (5736)

gruss

[sirius]

Aber bitte auch nicht SuspendThread nehmen. Ist ja nur der API Aufruf, der in TThread.Suspend gekapselt wird. Auch msdn schreibt, dass man SuspendThread nur zum Debuggen nehmen soll. Allerdings steht nirgends etwas darüber, warum man SuspendThread nicht aus dem eigenen Thread heraus aufrufen kann. Dennoch gibt es schönere / andere Methoden:

Delphi-Quellcode:

{ TmyThread }
private
  FHaltEvent:TEvent;

//...

procedure TmyThread.Continue;
begin
  FHaltEvent.SetEvent;
end;

constructor TmyThread.Create(aSuspended: boolean);
begin
  inherited;
  FHaltEvent:=TEvent.Create(nil,true,true,'');
end;

destructor TmyThread.Destroy;
begin
  FHaltEvent.Free;
  inherited;
end;

procedure TmyThread.execute;
begin

  while not terminated do
  begin
    //do something


    SuspendIfHalted;
  end;


end;

procedure TmyThread.Halt;
begin
  FHaltEvent.ResetEvent;
end;

function TmyThread.Halted: boolean;
begin
  result:= FHaltEvent.WaitFor(0) <> wrsignaled;
end;

procedure TmyThread.SuspendIfHalted;
begin
  FHaltEvent.WaitFor(infinite);
end;


procedure TmyThread.Terminate;
begin
  if Halted then FHaltEvent.SetEvent;
  inherited;
end;

[Tryer]

SuspendThread

Zitat:

To avoid this situation, a thread within an application that is not a debugger should signal the other thread to suspend itself

Genau das mache ich in dem Beispiel. Suspend könnte man dabei an Stelle von SuspenThread genauso gut verwenden und die Warnung ignorieren - da es so halt "richtig" angewendet wird und Deadlocks ausgeschlossen sind.
Die optionale Verwendung von Events oder Sleep hatte ich ja bereits genannt, siehe auch Suspending Thread Execution
Wie auch in der Delphi-Hilfe werden in jedem MSDN-Artikel leider nur Teilaspekte angesprochen.

Grüsse, Dirk

[sirius]

Zitat von Tryer:

Wie auch in der Delphi-Hilfe werden in jedem MSDN-Artikel leider nur Teilaspekte angesprochen.

Und so ein Teilaspekt ist halt auch folgender:
(Suche nach "SuspendThread race condition")

Zitat:

The reason is related to a possible race condition with the suspend count.
The suspend count is incremented by a call to SuspendThread(), and is
decremented by a call to ResumeThread(). If the suspend count is non-zero,
then the scheduler will mark the thread as "waiting" (or not ready), and
will not schedule the thread for processing; conversely, when the suspend
count is exactly zero, the thread is marked as "ready" and is given
processing time. The race condition occurs because access to the suspend
count is not synchronized between threads, such that it is possible for one
thread to decrement the suspend count beyond zero to a value of -1. At that
value, the thread will never be scheduled for processing.

[EWeiss]

Kann sich nochmal bitte jemand dieser Frage annehmen?
http://www.delphipraxis.net/1118970-post19.html

gruss

[sirius]

Zitat von EWeiss:

Kann sich nochmal bitte jemand dieser Frage annehmen?
http://www.delphipraxis.net/1118970-post19.html

gruss

1. Such dir halt einen Namen aus (suspend ist ja leider schon vergeben; genauso: break und interrupt) Stop wäre noch übrig. Aber dann neigt man beim weitermachen dazu start zu verwenden, was ja schon vergeben ist. Das Antonym für continue ist ja discontinue. Gibts aber zumindest in meinem aktiven Wortschatz bisher nicht. Naja, lass dir was einfallen....

2. CriticalSection ist ein Handle-Objekt. EnterCriticalSection ist eine Funktion auf dieses Handle-Objekt.
TCriticalSection ist eine Klasse, welches das Handle-Objekt CriticalSection kapselt. TCriticalsection.EnterCriticalSection ist eine Methode vorheriger Klasse.
Was war eigentlich genau deine Frage?

Deine 3. Frage verstehe ich nicht.

[EWeiss]

Zitat:

2. CriticalSection ist ein Handle-Objekt. EnterCriticalSection ist eine Funktion auf dieses Handle-Objekt.
TCriticalSection ist eine Klasse, welches das Handle-Objekt CriticalSection kapselt. TCriticalsection.EnterCriticalSection ist eine Methode vorheriger Klasse.

Habe dann wohl was falsch gemacht.
Dann habe ich zwar das Handle object erstellt aber keine Function welche das handle verwaltet (bzw. damit arbeitet)

Die Frage war ..
An welcher stelle ist es sinnvoll EntercriticalSection und LeaveCriticalSection in TVisDataThread.Execute unterzubringen?

wo könnte hier etwas Kritisch sein das ich EntercriticalSection verwenden muss, sollte?
Muss mal bei MS lesen wofür EntercriticalSection genau steht
Verstehe die Anwendung der Function wohl noch nicht!

gruss

[Tryer]

Zitat:

The race condition occurs because access to the suspend
count is not synchronized between threads, such that it is possible for one
thread to decrement the suspend count beyond zero to a value of -1.

Da ausschliessliuch der Thread selber SuspendCount verringert seh ich darin kein Problem - auch wieder ein Fall wo nur das Suspend aus einem anderen Thread zum Fehler führt.

[sirius]

Zitat von Tryer:

Zitat:

The race condition occurs because access to the suspend
count is not synchronized between threads, such that it is possible for one
thread to decrement the suspend count beyond zero to a value of -1.

Da ausschliessliuch der Thread selber SuspendCount verringert seh ich darin kein Problem - auch wieder ein Fall wo nur das Suspend aus einem anderen Thread zum Fehler führt.

Eben nicht.
Dieses Problem tritt auf, wenn TmyThread Suspend aufruft und der MainThread gleichzeitig Resume aufruft, was bei deinem Code durchaus passieren kann.

Zitat von Emil:

FDelayMSChanged
FDelayMSChanged wird aufgerufen wenn ein neues Plugin gestartet wird und die ms sich geändert haben.

Dann must du um jeden Zugriff (eigentlich nur, wenn mindestens ein Thread auch schreibend darauf zugreift) EnterCriticalSection und LeaveCriticalSection basteln (und zwar von der exakt gleichen Objektinstanz)
Allerdings hast du hier eine Variable allersimplesten Datentypes. Da reichen die interlocked-Funktionen aus und die synchronisation kann entfallen.

[EWeiss]

Zitat:

Allerdings hast du hier eine Variable allersimplesten Datentypes. Da reichen die interlocked-Funktionen aus und die synchronisation kann entfallen.

Was bedeutet das ich LockFlag sowie EnterCriticalSection gar nicht verwenden muss?

Mir ging es eigentlich darum eventuelle hänger beim umschalten auf andere Plugins zu vermeiden.
Dafür scheint dann wohl EnterCriticalSection nicht das richtige zu sein.

Hab dann wohl was falsch verstanden..

Danke für deine Hilfe

gruss