[Java] zijn statics synchronised?

[hobbit_be]

heel simpel:

Java:

class whatever
{
   static synchronized private boolean mTaskRunning;
}

compileerd by my niet, ben al gaan zoeken maar kom op verscheidende
'tegenspreuken'.

hoe moet je 'global' dan synchen?

[nxt]

volgens mij moet dat door de variabele te gebruiken in een synchronized blok
variabelen zelf kun je voor zover ik weet niet synchronized maken

Java:

synchronized(mTaskRunning) {
    //doe hier iets met mTaskRunning
}

[Soultaker]

eZoals nxt al aangaf, kun je attributen helemaal niet synchronized maken (static of niet). Je kunt dus beter statische methoden gebruiken voor het benaderen van het static attribuut:

Java:

private static boolean mTaskRunning = false;
private static Object lockTaskRunning = new Object();

public static boolean getTaskRunning()
{
    synchronized(lockTaskRunning) {
        return mTaskRunning;
    }
}

public static boolean setTaskRunning(boolean value)
{
    synchronized(lockTaskRunning) {
        mTaskRunning = value;
    }
}

Of iets dergelijks.

[ Voor 7% gewijzigd door Soultaker op 11-05-2003 22:33 ]

[hobbit_be]

DOH! das erug lomp van me ! sorry voor de vraag - wel jammer dat het niet bestaat (ie een soort van Mutex als standaard type leek me wel 'Java')..

Thx Soultaker - net wat ik wou weten

[mbravenboer]

Mutex komt in 1.5 als onderdeel van de concurrecy API van Doug Lea.

http://gee.cs.oswego.edu/...til/concurrent/Mutex.html
http://www.jcp.org/en/jsr/detail?id=166

[Glimi]

Wat is een mutex meer dan een object met een boolean en een synchronized up() method?

[edit] Het is ook niet veel meer zie ik al

[mbravenboer]

Idd, slechts een beetje abstractie en terminologie. Toch kan dat wel nuttig en verfrissend zijn.

[ Voor 10% gewijzigd door mbravenboer op 12-05-2003 09:46 ]

[Glimi]

mbravenboer schreef op 12 mei 2003 @ 09:46:
Idd, slechts een beetje abstractie en terminologie. Toch kan dat wel nuttig en verfrissend zijn.

Eigenlijk vind ik het raar dat het er nu pas aan komt, ik zat gisteren ook al verbaasd in de API te bladeren. Het is immers zo'n essentieels iets voor Concurrency.
En ook heeft iedereen wel binnen 10 minuten z'n eigen mutex in elkaar, lijkt het me toch een uitermate mooi iets voor een lib, juist omdat er zoveel gebruik van gemaakt wordt, waardoor een stukje meer uniformie ontstaat

[ Voor 50% gewijzigd door Glimi op 12-05-2003 10:34 ]

[mbravenboer]

Glimi: Eigenlijk vind ik het raar dat het er nu pas aan komt

Tja, niemand houdt je natuurlijk tegen om het spul van Doug Lea nu al te gebruiken . Op zich heeft het ook wel weer iets om even te wachten met niet atomaire functionaliteit: met een vroege library van Sun zelf was er nu waarschijnlijk niet zulk goed werk opgenomen van een andere partij .

[Verwijderd]

mutex

Zijn monitors, zoals in Java, juist niet voorgesteld als verbetering van bijv. een mutex?

[curry684]

Wat is een mutex meer dan een object met een boolean en een synchronized up() method?

Feut

Een echte mutex houdt het FIFO-concept in stand door de langst-wachtende thread als eerste te releasen, dat kan niet met een simpele boolean. Tevens beschermt een echte mutex je tegen recursieve locks zodat een thread niet kan deadlocken op zichzelf.

[Soultaker]

curry684 schreef op 12 May 2003 @ 17:09:
Een echte mutex houdt het FIFO-concept in stand door de langst-wachtende thread als eerste te releasen, dat kan niet met een simpele boolean. Tevens beschermt een echte mutex je tegen recursieve locks zodat een thread niet kan deadlocken op zichzelf.

Wie zegt dat? Voor zover ik weet staat 'mutex' gewoon voor 'mutual exclusion' en Glimi's omschrijving voldoet daar perfect aan. Uiteraard is het bevorderen van voortgang (of het detecteren van deadlocks) erg handig, maar voor zover ik weet is het geen voorwaarde om de naam 'mutex' te rechtvaardigen.

Overigens kan dezelfde thread zonder problemen toegang van een monitor verkrijgen als die al eerder door diezelfde thread gelocked was, dus een mutex geïmplementeerd op basis van zo'n zelfde monitor heeft ook dit eigenschap. FIFO-gedrag wordt niet gegarandeerd voor Java monitors; terecht, lijkt me, als je bedenkt dat in veel situaties andere schema's efficienter of anderszins wenselijker zijn.

[curry684]

Soultaker schreef op 12 May 2003 @ 17:27:
Wie zegt dat? Voor zover ik weet staat 'mutex' gewoon voor 'mutual exclusion' en Glimi's omschrijving voldoet daar perfect aan. Uiteraard is het bevorderen van voortgang (of het detecteren van deadlocks) erg handig, maar voor zover ik weet is het geen voorwaarde om de naam 'mutex' te rechtvaardigen.

Inderdaad, een mutex is niets anders dan een volatile bool in essentie, daarom had ik het ook over een 'echte mutex' zoals die in relevante API's wordt gebruikt zoals pthreads en Win32. Een volatile bool is geen synchronization object omdat het niet aan de basale eisen van synchronizatie voldoet, zoals het zorgen voor een beveiligd correct voortschrijden van een programma. Bij 3 threads die locken op dezelfde mutex zonder FIFO-mechanisme krijg je onherroepelijk race conditions waardoor 1 thread lange tijd gestarved kan worden. Oftewel nutteloos voor praktijkgebruik.

Overigens kan dezelfde thread zonder problemen toegang van een monitor verkrijgen als die al eerder door diezelfde thread gelocked was, dus een mutex geïmplementeerd op basis van zo'n zelfde monitor heeft ook dit eigenschap. FIFO-gedrag wordt niet gegarandeerd voor Java monitors; terecht, lijkt me, als je bedenkt dat in veel situaties andere schema's efficienter of anderszins wenselijker zijn.

Een bool kan niet recursief locken, want de binnenste lock zal de lock vrijgeven bij unlock waardoor een gedeelte van de buitenste locks niet gesynchroniseerd zal verlopen.

En nu heb ik van Java al niet een al te hoge pet op, maar als synchronization objects die het in de standaard maken niet aan FIFO doen en daarmee expres nog harder de performance om zeep helpen dan Java op zichzelf al doet mag het van mij nog harder de vuilnisbak in dan vantevoren.

[curry684]

Ter illustratie een stukje uit de Win32 API's, waar een CriticalSection object bestaat als de lightweight process-local tegenhanger van de system-wide Mutex. Met wat geneus in de headers kun je de volgende definitie van een CriticalSection terugvinden:

C++:

typedef struct _RTL_CRITICAL_SECTION {
    PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
    LONG LockCount;
    LONG RecursionCount;
    HANDLE OwningThread;        // from the thread's ClientId->UniqueThread
    HANDLE LockSemaphore;
    ULONG_PTR SpinCount;        // force size on 64-bit systems when packed
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;

Ik vind het nogal disrespectvol om dit een veredelde boolean te noemen

[Soultaker]

curry684 schreef op 13 mei 2003 @ 00:03:
Inderdaad, een mutex is niets anders dan een volatile bool in essentie, daarom had ik het ook over een 'echte mutex' zoals die in relevante API's wordt gebruikt zoals pthreads en Win32. Een volatile bool is geen synchronization object omdat het niet aan de basale eisen van synchronizatie voldoet, zoals het zorgen voor een beveiligd correct voortschrijden van een programma.

Wie bepaalt er dan wat een 'echte mutex' is, als we het er al over eens waren wat een mutex pur sang is? Welke 'basale eisen' heb je het over, en wie stelt die vast? Nu ga je gewoon langs mijn commentaar heen en probeer je je met een verzameling vaagheden een duidelijke discussie te ontlopen.

Bij 3 threads die locken op dezelfde mutex zonder FIFO-mechanisme krijg je onherroepelijk race conditions waardoor 1 thread lange tijd gestarved kan worden. Oftewel nutteloos voor praktijkgebruik.

Dat is niet waar. Er zijn een heleboel mechanismen denkbaar die niet tot starvation lijden en ook zeer bruikbaar zijn. Veel bruikbaarder, misschien wel: zo kan ik me voorstellen dat je het toewijzen van een mutex wilt doen op basis van de (dynamische) prioriteit van de verschillende threads die er op wachten, zodat je het gemiddelde processorverbruik eerlijker verdeeld dan met een FIFO-schema. Duidelijk is dat ook hierbij geen starvation optreedt.

De Java standaard zegt dat bij een implementatie een willekeurig zinnig schema gekozen mag worden. Een simpel FIFO-schema werkt best aardig, maar sommige besturingssystemen bieden meer geavanceerde mechanismen die wel eens beter kunnen werken. Er zijn een heleboel zaken die een bij het implementeren van een Java-omgeving vrijelijk te kiezen zijn en bij allemaal kunnen stomme fouten gemaakt worden. Dat die mogelijkheid bestaat is nauwelijks af te schuiven op de ontwerpers van het Java platform; je mag er van uit gaan dat er bij de implementatie een redelijk zinnige variant gekozen is (maar niet noodzakelijkerwijs een of andere bepaalde variant).

Een bool kan niet recursief locken, want de binnenste lock zal de lock vrijgeven bij unlock waardoor een gedeelte van de buitenste locks niet gesynchroniseerd zal verlopen.

Ik snap niet wat je hier zegt en ik weet niet of het van belang is voor de discussie. Ik zie niet in hoe een 'bool', wat niet meer dan een wiskundig datatype is, ueberhaupt zou kunnen locken. Als je wat duidelijker uit zou kunnen leggen wat je hiermee bedoelt, zou ik het misschien kunnen ontkrachten?

[ACM]

curry684 schreef op 13 May 2003 @ 00:03:

Java:

class locker
{
  private final Object objectLock = new Object();

  private void outerFunction()
  {
      synchronized(objectLock)
      {
          // Dit zou dus moeten deadlocken?
          innerFunction();
      }
  }

   private void innerFunction()
   {
       synchronized(objectLock)
       {
           // Maar dat deadlocked niet hoor :)
       }
   }
}

Is bovenstaande code wat jij bedoeld met recursieve locks? En dat zou volgens jou fout moeten gaan in Java?

Dat gaat goed hoor

[ Voor 16% gewijzigd door ACM op 13-05-2003 09:24 ]

[Alarmnummer]

ACM schreef op 13 mei 2003 @ 09:23:
Is bovenstaande code wat jij bedoeld met recursieve locks? En dat zou volgens jou fout moeten gaan in Java?

Dat gaat goed hoor

Idd. De vm heeft gelukkig in de gaten als de thread al een lock heeft op dat object. Als de thread al een lock heeft, dan wordt er niet nog een geplaatst.

[ Voor 11% gewijzigd door Alarmnummer op 13-05-2003 09:32 ]

[curry684]

Iedereen even terug naar deze vraag van Glimi:

Wat is een mutex meer dan een object met een boolean en een synchronized up() method?

Daar reageerde ik op met dat een boolean mutex niet recursief kan locken en geen enkel prioritizing schema kan uitvoeren op de waiting threads

Dus iedereen die dacht dat ik Java implementaties af zat te kraken moet even overnieuw beginnen met lezen (en er begrip voor hebben dat ik door technische tekortkomingen hier op m'n werkplek extreem korte posts moet maken).

[Soultaker]

curry684 schreef op 13 mei 2003 @ 13:10:
Daar reageerde ik op met dat een boolean mutex niet recursief kan locken en geen enkel prioritizing schema kan uitvoeren op de waiting threads

Dus iedereen die dacht dat ik Java implementaties af zat te kraken moet even overnieuw beginnen met lezen (en er begrip voor hebben dat ik door technische tekortkomingen hier op m'n werkplek extreem korte posts moet maken).

Je bedoelt dus, met alleen een boolean? Daar kun je toch helemaal geen mutex mee bouwen, zelfs niet als je 'm volatile maakt, aangezien je niet tegelijkertijd de waarde van de boolean kunt evalueren en een nieuwe waarde instellen? Of je moet x86-instructies ervoor gebruiken, maar die zijn in een gangbare taal niet beschikbaar.

[ Voor 8% gewijzigd door Soultaker op 13-05-2003 20:11 ]

[curry684]

Soultaker schreef op 13 May 2003 @ 20:08:
[...]

Je bedoelt dus, met alleen een boolean? Daar kun je toch helemaal geen mutex mee bouwen, zelfs niet als je 'm volatile maakt, aangezien je niet tegelijkertijd de waarde van de boolean kunt evalueren en een nieuwe waarde instellen? Of je moet x86-instructies ervoor gebruiken, maar die zijn in een gangbare taal niet beschikbaar.

[rml]Glimi in "[ Java] zijn statics synchronised?"[/rml]

[ Voor 31% gewijzigd door curry684 op 13-05-2003 21:24 . Reden: gvdgvdgvdgvd aaargh edit 5 ]

[reddog33hummer]

code:

class whatever 
{ 
   private static boolean mTaskRunning;
   private static final synchronized boolean isTaskRunning()
   {
        return mTaskRunning;
   } 
}

Gewoon een static functie aanmaken die de file aanpast. Die kan namelijk wel synchronized zijn.

[.oisyn]

reddog33hummer: die "synchronized" zorgt nou juist voor de mutual exclusion, en derhalve is die hele boolean niet nodig:

Java:

class Bla
{
    Object mutex = new Object ();

    void func ()
    {
        synchronized (mutex) // dit zorgt voor mutual exclusion
        {
            // de code hier kan maar door 1 thread tegelijk uitgevoerd worden
        }
    }
}

[Soultaker]

curry684 schreef op 13 mei 2003 @ 21:23:
[rml]Glimi in "[ Java] zijn statics synchronised?"[/rml]

Glimi heeft het over een object met een boolean attribuut. Dat is dus méér dan alleen een boolean, aangezien het object een geassocieerde monitor heeft (die voor de synchronisatie zorgt).

Met alleen een boolean waarde kun je (in Java) volgens mij geen mutex maken, maar met object en een boolean waarde wel!

[ACM]

Soultaker schreef op 14 May 2003 @ 19:41:
Met alleen een boolean waarde kun je (in Java) volgens mij geen mutex maken, maar met object en een boolean waarde wel!

Met een Boolean wel

Maar ook alleen maar omdat de synchronized functionaliteit er al is natuurlijk

[Soultaker]

ACM schreef op 14 May 2003 @ 21:05:
Met een Boolean wel

Maar ook alleen maar omdat de synchronized functionaliteit er al is natuurlijk

Hmm, inderdaad... bijdehandje!

[.oisyn]

ACM schreef op 14 mei 2003 @ 21:05:
Maar ook alleen maar omdat de synchronized functionaliteit er al is natuurlijk

Dan gebruik je dus een boolean en een object