Results 1 to 7 of 7

Thread: Object properties lezen uit draaiende TThread

  1. #1

    Object properties lezen uit draaiende TThread

    Ik heb een TThread die een eigen object bouwd met een aantal properties, deze properties worden door de thread gewijzigd zonodig.

    Is het "thread-safe" om de properties van dit object uit te lezen via bijv. een TButton op een form?

    De thread heeft een property naar het Object

    De aanroep ziet er dan uit als showmessage(thread object str. property value: ' + Thread.Obj.prop);
    Het zetten van de properties doet de thread als deze via een postthreadmessage hier opdracht voor krijgt.

    Ik kan me voorstellen dat dit met een CriticalSection moet maar misschien is dat helemaal niet nodig?
    Leonmeijer

  2. #2
    Ex-Student
    Join Date
    Feb 2004
    Location
    Leeuwarden
    Posts
    2,409
    Voor uitlezen heb je geen critical sections nodig. Dat doe je alleen bij het setten van een waarde die beheert worden door meerdere threads om te voorkomen dat je met verkeerde waardes rekent enzo (een terugkerende voorbeeld is altijd weer de banksaldo).

  3. #3
    Fornicatorus Formicidae VideoRipper's Avatar
    Join Date
    Mar 2005
    Location
    Vicus Saltus Orientalem
    Posts
    5,708
    Quote Originally Posted by Cornelis View Post
    critical sections [...] (een terugkerende voorbeeld is altijd weer de banksaldo).
    Dat is bij mij inderdaad ook altijd een terugkerend kritiek iets
    TMemoryLeak.Create(Nil);

  4. #4
    Senior Member
    Join Date
    May 2011
    Location
    Oisterwijk
    Posts
    468
    Quote Originally Posted by Leonmeijer View Post
    Ik heb een TThread die een eigen object bouwd met een aantal properties, deze properties worden door de thread gewijzigd zonodig.

    Is het "thread-safe" om de properties van dit object uit te lezen via bijv. een TButton op een form?

    De thread heeft een property naar het Object

    De aanroep ziet er dan uit als showmessage(thread object str. property value: ' + Thread.Obj.prop);
    Het zetten van de properties doet de thread als deze via een postthreadmessage hier opdracht voor krijgt.

    Ik kan me voorstellen dat dit met een CriticalSection moet maar misschien is dat helemaal niet nodig?
    Eerst wat vragen
    - Wordt het object door meer dan 1 proces gebruikt, en zo ja kan dat (bijna) tegelijk zijn?
    - Wordt er alleen gelezen, of ook geschreven?
    - Als er geschreven wordt, is het dan een atomic write (boolean, integer)?
    Bij 3x ja moet je zeker locken, bijvoorbeeld met critical sections.

    Wat ik dan graag doe om het makkelijk te houden,
    - bij batch of scannende threads is dat als we wat vinden dat ze dat live terugkoppelen met een synchronized call naar de VCL thread, die dan even een property van de thread uitleest. Voortgang of status terugkoppelen werkt hetzelfde.
    - bij threads die tegelijk in dezelfde lijst/object werken wil je een critical section geven in de betreffende lijst/object zodat die threadsafe wordt, en je die gewoon careless kan gebruiken in elke thread.

    Dus critical sections zijn ontzettend mooi maar vaak kan je jezelf net zo goed de moeite besparen, als je ontwerp ook zonder kan.

  5. #5
    Het object wordt in de thread aangemaakt en alleen door die thread en de VCL (main) thread uitgelezen, niet door andere processen of threads.
    Er wordt naar het object geschreven als de VCL een postthreadmessage naar de thread stuurt om de thread een JSON (superobject) te laten ophalen van een webserver, deze JSON wordt uitgelezen en als properties aan het object toegevoegd.
    De VCL hoeft alleen bij het showen van een form even alle properties uit te lezen om sliders op de juiste plek te zetten en informatie labels te vullen (dit hoeft niet constant te gebeuren vanuit de thread dmv bijv. een synchronize).
    De properties zjin boolean, integer, double en string.
    Leonmeijer

  6. #6
    Het zal wel slimmer kunnen maar ik doe het altijd zo:

    Code:
    type TInfo = packed record
                         updated : integer;
                         progress : integer;
                      end;
    
    var  ARecord : TInfo;
    
    THREAD:
      if updated = 0 then
      begin
         progress := <interne status>
         updated := 1; 
      end;
    end;
    
    MAIN-THREAD:   (of TTimer ding met vaste interval)
      repeat
         if updated <> 0 then
         begin
            progressbar1.position := progress;
            updated := 0; 
         end;
         application.processmessages;
      until progressbar1.position = 100;

    Tja het is pseudo code, maar ik hoop dat je het idee snapt.
    Last edited by feature3003; 26-Feb-13 at 12:13. Reason: ging iets fout met posten

  7. #7
    Ja ook aan gedacht maar vond dit makkelijker toekennen.
    Leonmeijer

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •