Wie war das noch mit volatile in C ?

[Stefan (Gast)]

glib-2.43.90/gobject/gobject.c

/**
 * g_clear_object: (skip)
 * @object_ptr: a pointer to a #GObject reference
 *
 * Clears a reference to a #GObject.
 *
 * @object_ptr must not be %NULL.
 *
 * If the reference is %NULL then this function does nothing.
 * Otherwise, the reference count of the object is decreased and the
 * pointer is set to %NULL.
 *
 * A macro is also included that allows this function to be used without
 * pointer casts.
 *
 * Since: 2.28
 **/
#undef g_clear_object
void
g_clear_object (volatile GObject **object_ptr)
{
  g_clear_pointer (object_ptr, g_object_unref);
}

Mir fällt gerade nicht ein, warum hier volatile bei dem Parameter 
verwendet wird. An volatile im Zusammenhang mit ISR erinnere ich mich 
schon, aber diese Funktion wird ja nicht vom Interrupt aufgerufen. Aber 
was soll's, eine dumme Frage mehr, und ich muss jetzt eh weg.

[Clemens L. (c_l)]

Es ist möglich, sich sein eigenes GObject(-abgeleitetes)-Objekt mit 
volatile zu definieren (z.B. weil es auch im ISR benutzt wird).
Ohne das volatile würde dann der Compiler beim Aufruf von 
g_clear_object() meckern.

[Programmierer (Gast)]

Kein Mensch verwendet aber die glib ohne Betriebssystem, also so dass 
man was mit Interrupts machen müsste. volatile hat nichts mit Interrupts 
zu tun, sondern mit Compiler Optimierungen. Und das kann bei 
Multithreading relevant sein. Allerdings bin ich mir nicht sicher dass 
man volatile da überhaupt korrekt anwenden kann, und man das nicht mit 
locks/atomics machen muss...

[Peter II (Gast)]

Programmierer schrieb:
> Allerdings bin ich mir nicht sicher dass
> man volatile da überhaupt korrekt anwenden kann, und man das nicht mit
> locks/atomics machen muss

eigentlich muss man beides machen. Nur ein PC hat meist recht wenig 
Register so das die Daten aus dem Ram kommen und nicht im Register 
verweilen. Damit reicht es oft aus ohne volatile zu arbeiten.

[Robert L. (lrlr)]

http://blog.regehr.org/archives/28


habs zwar nicht gelesen, aber was soll's, eine dumme Antwort mehr, und 
ich muss jetzt eh weg.

[Kenner (Gast)]

http://www2.informatik.uni-halle.de/lehre/c/c_volat.html

[Stefan S. (Gast)]

Programmierer schrieb:
> volatile hat nichts mit Interrupts
> zu tun, sondern mit Compiler Optimierungen. Und das kann bei
> Multithreading relevant sein. Allerdings bin ich mir nicht sicher dass
> man volatile da überhaupt korrekt anwenden kann, und man das nicht mit
> locks/atomics machen muss...

Ja, an Multithreading hatte ich auch kurz gedacht, aber ohne konkrete 
Idee was das Problem sein könnte. Compiler Optimierungen ist auch ein 
gutes Stichwort, aber auch da wüsste ich nicht was konkret schiefgehen 
könnte.

Tatsächlich habe ich bei meiner Nim-Version von 
gtk+-3.18.1/examples/application10 mit dieser Funktion ein kleines 
Problemchen -- wenn ich aber das gleichnamige Macro verwende, geht es.

Das ist eh etwas komisch, in

glib-2.43.90/gobject/gobject.h

haben wir:

GLIB_AVAILABLE_IN_ALL
void    g_clear_object (volatile GObject **object_ptr);
#define g_clear_object(object_ptr) g_clear_pointer ((object_ptr), g_object_unref)

Wer also nicht explizit dieses Macro zurücksetzt, wird ja wohl stets das 
Macro, und nicht die Funktion verwenden.

[Stefan S. (Gast)]

Na jedenfalls bin ich wohl nicht der Einzige der das nicht so recht 
versteht. Hier etwa rätseln sie auch:

http://stackoverflow.com/questions/9363899/why-mark-function-argument-as-volatile

DMA oder multihreading wäre sicher eine Möglichkeit.

Tatsächlich ist es so, dass ich Probleme bekomme, wenn ich einen VAR 
Parameter verwende, während es mit einem Pointer geht. Aber ich habe 
jetzt doch mal im Nim Forum nachgefragt. Vielleicht hat das Problem auch 
mit volatile gar nichts zu tun.