TThread mit WaitForMultipleObjects in DLL arbeitet nicht ?

[Rumpi]

Hallo,

Delphi-Quellcode:

unit cl_Thread;

interface
  uses Windows, Classes, syncobjs, Sysutils;

type

  TTimerThread = class(TThread)
  private
    { Private-Deklarationen }
    FEnabled     : Boolean;
    FOneSec      : Boolean;
    FOnNotify    : TNotifyEvent;
    FInterval    : Longint;
    FTag         : Longint;
    FCloseEvent  : TSimpleEvent;
    FEnableEvent : TSimpleEvent;
    FLastSec     : Word;
  public
    constructor Create( OnNotify: TNotifyEvent ); overload;
    constructor Create( aInterval: Longint; OnNotify: TNotifyEvent ); overload;
    destructor  Destroy; override;
    procedure   Stop;
  protected
    procedure Execute; override;
    procedure Notify;
    procedure SetEnabled( Value: Boolean );
    procedure SetInterval( Value: Longint );
  published
    property Interval: Longint read FInterval write SetInterval;
    property Enabled : Boolean read FEnabled write SetEnabled;
    property Tag     : Longint read FTag write FTag;
  end;

implementation

constructor TTimerThread.Create( OnNotify: TNotifyEvent );
begin
  inherited Create( True );
  FreeOnTerminate := True;
  FOnNotify     := OnNotify;
  FInterval     := 50;
  FCloseEvent   := TSimpleEvent.Create;
  FEnableEvent  := TSimpleEvent.Create;
  FEnabled      := True;
  FOneSec       := True;
  Resume;
end;

constructor TTimerThread.Create( aInterval: Longint; OnNotify: TNotifyEvent );
begin
  inherited Create( True );
  FreeOnTerminate := True;
  FOnNotify   := OnNotify;
  FInterval   := aInterval;
  FCloseEvent := TSimpleEvent.Create;
  FEnableEvent:= TSimpleEvent.Create;
  FEnabled    := False;
  FOneSec     := False;
  Resume;
end;

destructor TTimerThread.Destroy;
begin
  FCloseEvent.Free;
  Inherited Destroy;
end;

procedure TTimerThread.Execute;
var
  Signaled    : Integer;
  h, m, s, ms : Word;
  EventHandles: array[0..1] of THandle;
begin
  EventHandles[0] := FCloseEvent.Handle;
  EventHandles[1] := FEnableEvent.Handle;
  repeat
    Signaled := WaitForMultipleObjects( 2, @EventHandles, False, FInterval );
    case Signaled of

      // Close event, terminate the thread
      WAIT_OBJECT_0 :
        begin
          ResetEvent(FCloseEvent.Handle);
          Break;
        end;

      WAIT_OBJECT_0 + 1:
        begin
          ResetEvent(FEnableEvent.Handle);
          FEnabled := True;
        end;

      //
      WAIT_TIMEOUT  :
        if Not FOneSec then
          Synchronize(Notify)
        else
        begin
          // Has a second passed ?
          DecodeTime( Now, h, m, s, ms );
          if s <> FLastSec then
          begin
            //Notify;
            Synchronize(Notify);
            FLastSec := s;
          end;
        end;

    end;
  until Terminated;
end;

procedure TTimerThread.Notify;
begin
  if Assigned( FOnNotify ) and FEnabled then
    FOnNotify( Self );
end;

procedure TTimerThread.Stop;
begin
  FEnabled := False;
  SetEvent(FCloseEvent.Handle);
end;

procedure TTimerThread.SetEnabled( Value: Boolean );
begin
  if FEnabled <> Value then
    if Value then
      SetEvent(FEnableEvent.Handle)
    else
      FEnabled := False;
end;

procedure TTimerThread.SetInterval( Value: Longint );
begin
  if FEnabled then
  begin
    FEnabled  := False;
    FInterval := Value;
    SetEvent(FEnableEvent.Handle);
  end
  else
    FInterval := Value;
end;


end.

TTimerThread funtioniert solange man ihn aus einer Application startet,
aber nicht in einer DLL :shock: ... Warum :gruebel: ?

Bleibt bei WaitForMultipleObjects stehen obwohl ein Interval gesetzt ist :wall: !

Ich musste also wieder zu TTimer :cry: greifen, aber ich würde gerne
TTimerThread auch in DLL's verwenden wollen.

Kann mir das mal einer erklären :?:

mfg Rumpi

[Rumpi]

Kann mir keiner Helfen ?

mfg Rumpi

[edit=Daniel B]Doppelpost gelöscht. Mfg, Daniel B[/edit]
[edit=Daniel B]BB-Code wieder eingeschaltet. Mfg, Daniel B[/edit]

[Christian Seehase]

Moin Rumpi,

:warn:

findest Du es nicht auch reichlich übertrieben, nach 2,5 Stunden Deinen Thread zu pushen?

[Rumpi]

So war das nicht gemeint. :shock:
Das ist nur eine Frage und kein Pushen. :?

mfg Rumpi

[Sharky]

Hai Rumpi,

ich bin mir sicher das jemand antwortet wenn er die Antwort kennt.

Pushen (ob mit absicht oder nicht) innerhalb von weniger als 24h ist halt nicht die feine Art.

[Bernd Ua]

Hi ungeduldiger,

so ausm Bauch - schau dir mal an, ob in der DLL die Varaible IsMultiThread auf true gesetzt
ist oder nicht und setze sie ansonsten auf true.

Dein Timer ist übrigens ein toller Plan - denk aber daran, dass das reale Intervall
gleich "eingestelltes Intervall + Ausführungszeit Eventhandler" ist, da Dein Synchronize
den Thread anhält

Bernd

[Rumpi]

Vielen Danke Bernd für den Input,

Ich habe die Variable auf True gesetzt aber es tut sich nix.
Es ist echt komisch, alle anderen Threads mit WaitForMultipleObjects
ohne einen TimeOut gehen ja ( Lesen einer RS232 EventFlags ).

Ich versuche Timer so gut es geht zu meiden.

Danke für deinen Hinweis mit Synchonize( X ),
bei meinen Funktionen ist das genau so gewollt,
der TimerThread soll erst danch wieder den Intervall starten.

mfg Rumpi

[Luckie]

Zitat:

Zitat von Bernd Ua

so ausm Bauch - schau dir mal an, ob in der DLL die Varaible IsMultiThread auf true gesetzt
ist oder nicht und setze sie ansonsten auf true.

Sollte eigentlich überflüssig sein, da er die VCL Thread-Klasse benutzt. Beim erzeugen des Threads wir die Variable automatisch auf True gesetzt. Man muss es nur von Hand machen, wenn man die API Funktion CreateThread ohne den Delphi Wrapper BeginThread benutzt. :wink:

[Bernd Ua]

Moin Rumpi,

jetzt bin ich ein bisschen wacher :)

Eigentlich sollte nix dagegen sprechen, dass WaitForMultipleObjects auch in DLLs
funktioniert. Interessehalber habe ich deinen Thread mal in ein Projekt kopiert und
aus ner DLL laufen lassen. Da hängt sich nix auf und bleibt nix stehen.

Das dumme ist, dass in Deinem Profil und der frage nix zur Delphi Version steht
(... und dass ich normalerweise Synchronize meide <g>).

Die Implementierung von Synchronize hat sich zwischen D5 und D6 geändert ( wg Crossplatform).

Fall D5 oder kleiner :
Bei D5 stellt Synchronize eine Nachricht mit einem Pointer auf den Thread in die
Nachrichtenschleife der Applikation (CM_EXECPROC) die zu einem Deadlock führt,
wenn die Applikation im Haupthread gerade auf irgendwas mit WaitForMultipleObjects wartet
( einer der Gründe warum ich Synchronize meide :zwinker: )
Ersetze dann mal spasseshalber Dein WaitForMultipleObjects durch MsgWaitForMultipleObjects !

Fall D6 oder höher
Synchronize erzeugt ein Event und stellt das Event in eine globale Variable namens SyncList ein (Unit Classes)
die bei GUI Applikationen automatisch ansonsten manuell über CheckSynchronize geprüft werden kann.
Hier haben DLL und EXE zweimal die globale Variable SyncList, dummerweise bleibt die Synclist der Exe immer leer
und Dein Event wird nie gerufen.
Workaround hier: Aktiviere bei EXE und DLL Runtimepackages ( rtl sollte reichen)

Grüsse Bernd

@Luckie: war nicht mehr richtig wach gestern

[Rumpi]

Hi Bernd,

... vorab schon mal Danke :)

Zitat:

Zitat von Bernd Ua

Das dumme ist, dass in Deinem Profil und der frage nix zur Delphi Version steht
(... und dass ich normalerweise Synchronize meide <g>).

Ich verwende D6 und D7 ( manchmal auch noch D4 oder D1 ) sorry werde ich das nächste Mal angeben.

Zitat:

Zitat von Bernd Ua

Synchronize erzeugt ein Event und stellt das Event in eine globale Variable namens SyncList ein (Unit Classes)
die bei GUI Applikationen automatisch ansonsten manuell über CheckSynchronize geprüft werden kann.
Hier haben DLL und EXE zweimal die globale Variable SyncList, dummerweise bleibt die Synclist der Exe immer leer
und Dein Event wird nie gerufen.
Workaround hier: Aktiviere bei EXE und DLL Runtimepackages ( rtl sollte reichen)

Ich habe nur im TimerThread Synchronize weggelassen und schon gings :-D

Delphi-Quellcode:

  // Synchronize( Notify );  //  so gehts nur wenn in einer EXE
  Notify;                    //  und schon gehts auch in der DLL
                             //  hatte ich ja schon als Alternative im code

Ich musste "nicht" in der EXE und oder der DLL Runtimepackages aktivieren :gruebel:

Danke noch einmal Bernd.

mfg Rumpi