ich bin etwas erstaunt, dass mein Compiler (MSVC 10.0) folgenden Code kritisiert:

long volatile* p = static_cast<long*>(malloc(sizeof(long)));
free(p);

Die Compilerausgabe lautet:

error C2664: 'free' : cannot convert parameter 1 from 'volatile long *' to 'void *'

Nun stellt sich mir die Frage nach dem "Warum". Man bedenke, dass nicht der Pointer, sondern der referenzierte Long volatile ist.

Aus meiner Sicht gibt es, nach dem ISO-Standard, folgende implizite Konvertierungen:

void* - T*
T* - void*
0/nullptr - T*

wobei T für einen beliebigen Typ steht.

Aus welchem Grund muss ich das casten?

EDIT:

long volatile* p = static_cast<long*>(operator new(sizeof(long)));
operator delete(p);

Aufgrund der Verwendung von placement new möchte ich den operator new() direkt aufrufen. Ich bin mir darüber im klaren, dass damit der Konstruktor nicht aufgerufen wird

Das compiliert natürlich.

long volatile* p = new long;
delete p;

kk

Für das erste brauchst Du nämlich einen const_cast. Vielleicht geht damit auch die zweite Konvertierung.

Upps. Habe hier "erstes" und "zweites" vertauscht.

Das sollte eine Daumenregel sein: "Wenn Du glaubst, volatile benutzen zu müssen, liegst Du wahrscheinlich falsch."

Ich greife lesend von mehreren Threads auf eine Variable zu. Ich denke schon volatile zu brauchen.

Ich greife lesend von mehreren Threads auf eine Variable zu. Ich denke schon volatile zu brauchen.

Wenn keiner auf die Variable schreibt, brauchst Du kein volatile und wenn einer schreibt, brauchst Du ein Lock um _alle_ Zugriffe. Volatile verhindert ja nur, dass die Variable in einem Register gehalten wird. Aber die Zugriffe darauf sind so oder so in aller Regel nicht atomar.

Von daher hat Krümelkacker recht:

krümelkacker schrieb:
Das sollte eine Daumenregel sein: "Wenn Du glaubst, volatile benutzen zu müssen, liegst Du wahrscheinlich falsch."

Wenn keiner auf die Variable schreibt, brauchst Du kein volatile und wenn einer schreibt, brauchst Du ein Lock um _alle_ Zugriffe.

Alle können natürlich auch schreibend zugreifen. Ohne volatile bekomme ich das u.U. nicht mit. Der Schreibzugriff ist gelockt.

Ich greife lesend von mehreren Threads auf eine Variable zu. Ich denke schon volatile zu brauchen.

Falsch. Dafür sind "Atomics" bzw "Locks" da. Das hat mit dem volatile aus C und C++ wenig zu tun.

http://ddj.com/high-performance-computing/212701484
http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt

kk

Um das möglichst "verlustarm" zu gestalten gibt es read/write locks.

Falsch.

Nein
Es ist vom Programmablauf her nicht möglich, dass an den Stellen wo ich lese auch gleichzeitig geschrieben wird. Daher muss ich nur dafür sorgen, dass der Prozessor keine "falsche Sicht" auf den Inhalt der Variablen hat.

http://en.wikipedia.org/wiki/Volatile_variable schrieb:

The volatile keyword is basically worthless as a portable threading construct.

Edit: verwechselst du das eventuell mit Java? Dort hat volatile den von dir gewünschten Effekt.

eine solche barrier ergibt sich normalerweise automatisch, wenn man ohne selbstgebastelte konstrukte sicherstellt, dass der programmablauf so synchronisiert ist, dass beim lesen kein anderer schreiben kann. irgendwo wartet man auf irgendwas, und im warten ist die barrier drin

variable == 4711;
do {
	DoAwesomeStuffWithVariable();   // MT
}
while( variable == 4711 );

mov eax, OFFSET variable
mov [eax], 4711

@loop:
;
; call StartThread etc.
;
mov eax, OFFSET variable
mov eax, [eax]
cmp eax, 4711
je  @loop

Zeile 8-9 sind entscheidend. Ich möchte nicht, dass der Compiler denkt den Wert von variable sowieso im Register zu haben.

im neuen standars ist volatile mit einer ähnlichen bedeutung wie in java vorgesehen.

Das halte ich für eine sehr kühne Behauptung. Kannst Du das belegen? Wozu soll denn dann bitte Kapitel 29 ("Atomic operations library") des FCDs sein? Siehe auch Herb Sutter's Artikel mit dem Titel "volatile vs volatile".

kk

hustbaer schrieb:

im neuen standars ist volatile mit einer ähnlichen bedeutung wie in java vorgesehen.

Das halte ich für eine sehr kühne Behauptung. Kannst Du das belegen? Wozu soll denn dann bitte Kapitel 29 ("Atomic operations library") des FCDs sein? Siehe auch Herb Sutter's Artikel mit dem Titel "volatile vs volatile".

kk

Hm.
Dann hab' ich irgendwo wohl Mist aufgeschnappt.

Ich kann nur hoffen dass die Jungs noch ihre Meinung ändern, denn alles andere wäre IMO total doof.

krümelkacker schrieb:

Das sollte eine Daumenregel sein: "Wenn Du glaubst, volatile benutzen zu müssen, liegst Du wahrscheinlich falsch."

Ich greife lesend von mehreren Threads auf eine Variable zu. Ich denke schon volatile zu brauchen.

Das ist leider ein Irrglaube, der sich hartnäckig hält. Insbesondere von Leuten, die IO-Ports programmiert haben.

Volatile darf man nicht verwechseln mit einem Cache-Write-Back. Teilweise nimmt man für solche Zwecke auch "MemoryFences" oder "MemoryBarriers".

http://msdn.microsoft.com/en-us/library/ms684208%28VS.85%29.aspx

Insbesondere auf nicht cache-cohärenten Systemen muss man dafür Sorge tragen.

Ansonsten gibts ja noch conditions und signals, die man für sowas verwendet anstatt n volatile.

Woher soll/kann er wissen dass die Threads mit ihrer Arbeit fertig sind, und der Wert der Variable sich nichtmehr ändern kann?

Wenn er dazu Standardmechanismen wie WaitForSingleObject oder Condition-Variablen verwendet, dann beinhalten diese Mechanismen (also WaitForSingleObject bzw. die Condition-Variablen) bereits die nötigen Konstrukte (also Barriers/...).

Wenn er sich dazu selbst was gestrickt hat sieht die Sache natürlich anders aus. Dann müsste er genau wissen was er tun muss, um die Cache-Coherency sicherzustellen. Mit einigen Compilern (wie MSVC ab Version 8 - kann sein schon ab 7.1, weiss ich nimmer) reicht hier volatile, da diese acquire/release Semantik ala Java mit volatile verknüpfen.

Kurz: wer fragt ob er volatile braucht, sollte volatile nicht verwenden (und braucht es auch nicht), sondern lieber die Standardmechanismen zur Synchronisierung verwenden. Die dann auch sicherstellen dass man volatile eben nicht braucht, und auch keine expliziten Barriers o.ä.