Boost interprocess vs. Win32API - Versionsgeschichte

David am 23. Juni 2015 um 08:01 Uhr

2015-06-23T08:01:29Z

David: /* Win32 API */

2015-06-22T16:17:22Z

‎Win32 API

David: /* Win32 API */

2015-06-22T16:16:08Z

‎Win32 API

David am 22. Juni 2015 um 16:02 Uhr

2015-06-22T16:02:37Z

David: /* Win32 API */

2015-06-18T12:29:02Z

‎Win32 API

David: /* Boost interprocess */

2015-06-18T12:28:10Z

‎Boost interprocess

David am 18. Juni 2015 um 10:35 Uhr

2015-06-18T10:35:57Z

David am 18. Juni 2015 um 09:48 Uhr

2015-06-18T09:48:50Z

David: /* Ergebnis Win32API */

2015-06-18T08:25:03Z

‎Ergebnis Win32API

David: Die Seite wurde neu angelegt: „= Boost interprocess = Folgende C++ Klassen habe ich unter VS2013/Win8.1/64bit eingesetzt um Threads zu synchronisieren bzw. Code zu schützen. Eingesetzt ha…“

2015-06-18T08:24:32Z

Die Seite wurde neu angelegt: „= Boost interprocess = Folgende C++ Klassen habe ich unter VS2013/Win8.1/64bit eingesetzt um Threads zu synchronisieren bzw. Code zu schützen. Eingesetzt ha…“

Neue Seite

= Boost interprocess =

Folgende C++ Klassen habe ich unter VS2013/Win8.1/64bit eingesetzt um Threads zu synchronisieren bzw. Code zu schützen.

Eingesetzt habe ich die Boost 1.58 (Stand 18.06.2015).

<pre>
boost::interprocess::interprocess_mutex MyMutex;
boost::interprocess::interprocess_condition MyCondition;
boost::interprocess::interprocess_semaphore MySemaphore;
</pre>

Dabei habe ich komplette Funktionen mittels scoped_lock gesperrt:

<pre>
boost::interprocess::scoped_lock<boost::interprocess::interprocess_recursive_mutex> lock(reentrant_block);
</pre>

Desweiteren habe ich Signale für bestimmte Aktionen über die Condition ausgelösst:

<pre>
void func1()
{
...
MyCondition.post();
...
}

void func2()
{
...
boost::interprocess::scoped_lock<boost::interprocess::interprocess_mutex> lock(cond_read_mutex);
bool ret = cond_read_possible.timed_wait(lock, boost::get_system_time() + boost::posix_time::milliseconds(timeoutMS));
...
}
</pre>

=== Ergebnis Boost 1.58===

Der entwickelte Serverprozess hatte eine CPU Last von 2.5%, obwohl dieser im Leerlauf war. Die Last ist einfach nur durch das Warten begrenzt durch einen timeout entstanden.

Mögliches weiteres Problem: Was bewirkt eine Zeitumstellung bei einem Timeout mit absoluter Zeitangabe?

== Win32 API ==

Ich habe alle Stellen ausgetauscht gegen SRWLOCK und CONDITION_VARIABLE, die seit Windows 2008 bzw. Vista unterstützt werden (nicht unter XP oder W2003 bzw. älter). Der neue Code ist fast identisch zu dem Alten.

<pre>
SRWLOCK reentrant_block
SRWLOCK cond_write_srw;
CONDITION_VARIABLE cond_write_possible;

void Init()
{
InitializeSRWLock(&reentrant_block);

InitializeSRWLock(&cond_write_srw);
InitializeConditionVariable(&cond_write_possible);
}

void func_protected()
{
AcquireSRWLockShared(&reentrant_block);
...
ReleaseSRWLockShared(&reentrant_block);
}

void func_signal()
{
WakeAllConditionVariable(&cond_write_possible);
}

void func_wait_signal()
{
AcquireSRWLockShared(&cond_write_srw);
BOOL ret = SleepConditionVariableSRW(&cond_write_possible, &cond_write_srw, timeoutMS, CONDITION_VARIABLE_LOCKMODE_SHARED);

... // Hier muss noch ret ausgewertet werden
... // geschützter Code

ReleaseSRWLockShared(&cond_write_srw);
}

</pre>

== Ergebnis Win32API ==

Die Last des Servers im Leerlauf ist auf unter 0.01% gesunken.

Ein Test unter Last hat ergeben, dass der gesamte Prozess um 80% schneller abläuft.
Dies ist aber auch ein Hinweis, dass ich in meinem Design zu sehr von schnellen Locks abhängig bin.

← Nächstältere Version		Version vom 23. Juni 2015, 08:01 Uhr
Zeile 1:		Zeile 1:
		+	<metadesc> Vergleich der boost::interprocess mit Win32API SRWLOCKS und CONDITION_VARIABLES im Bezug zur CPU Last inklusive C++ Code Beispiele</metadesc>
		+
	Zurück zur [[Windows Entwicklung]]		Zurück zur [[Windows Entwicklung]]

← Nächstältere Version		Version vom 22. Juni 2015, 16:17 Uhr
Zeile 47:		Zeile 47:

	Ich habe alle Stellen ausgetauscht gegen SRWLOCK und CONDITION_VARIABLE, die seit Windows 2008 bzw. Vista unterstützt werden (nicht unter XP oder W2003 bzw. älter). Der neue Code ist fast identisch zu dem Alten.		Ich habe alle Stellen ausgetauscht gegen SRWLOCK und CONDITION_VARIABLE, die seit Windows 2008 bzw. Vista unterstützt werden (nicht unter XP oder W2003 bzw. älter). Der neue Code ist fast identisch zu dem Alten.
		+
		+	Achtung: Das ist nur ein Beispiel. Fehlerbehandlung (Return Codes, Exceptions,...) habe ich in diesem Beispiel nicht beachtet, mal abgesehen von Deadlocks.

	<source lang="cpp">		<source lang="cpp">

← Nächstältere Version		Version vom 22. Juni 2015, 16:02 Uhr
Zeile 91:		Zeile 91:
	Ein Test unter Last hat ergeben, dass der gesamte Prozess um 80% schneller abläuft.		Ein Test unter Last hat ergeben, dass der gesamte Prozess um 80% schneller abläuft.
	Dies ist aber auch ein Hinweis, dass ich in meinem Design zu sehr von schnellen Locks abhängig bin.		Dies ist aber auch ein Hinweis, dass ich in meinem Design zu sehr von schnellen Locks abhängig bin.
		+
		+	= Links =
		+
		+	* [http://www.boost.org boost.org]
		+	* [https://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx SRWLOCK auf MSDN]
		+	* [https://msdn.microsoft.com/de-de/library/windows/desktop/ms682052(v=vs.85).aspx CONDITION_VARIABLE auf MSDN]

← Nächstältere Version		Version vom 18. Juni 2015, 10:35 Uhr
Zeile 1:		Zeile 1:
		+	Zurück zur [[Windows Entwicklung]]
		+
	= Boost interprocess =		= Boost interprocess =

@@ Zeile 49: / Zeile 49: @@
 <source lang="cpp">
 SRWLOCK reentrant_block
 SRWLOCK cond_write_srw;
 CONDITION_VARIABLE cond_write_possible;
@@ Zeile 61: / Zeile 64: @@
+}
 void func_protected()
+{
@@ Zeile 68: / Zeile 73: @@
+}
 void func_signal()
+{

@@ Zeile 48: / Zeile 48: @@
 Ich habe alle Stellen ausgetauscht gegen SRWLOCK und CONDITION_VARIABLE, die seit Windows 2008 bzw. Vista unterstützt werden (nicht unter XP oder W2003 bzw. älter). Der neue Code ist fast identisch zu dem Alten.
-<pre>
+<source lang="cpp">
 SRWLOCK reentrant_block
 SRWLOCK cond_write_srw;
@@ Zeile 64: / Zeile 64: @@
+{
    AcquireSRWLockShared(&reentrant_block);
-   ...
+   //...
    ReleaseSRWLockShared(&reentrant_block);
+}
@@ Zeile 78: / Zeile 78: @@
    BOOL ret = SleepConditionVariableSRW(&cond_write_possible, &cond_write_srw, timeoutMS, CONDITION_VARIABLE_LOCKMODE_SHARED);
-   ... // Hier muss noch ret ausgewertet werden
+   //...  Hier muss noch ret ausgewertet werden
-   ... // geschützter Code
+   //...  geschützter Code
    ReleaseSRWLockShared(&cond_write_srw);
+}
+</source>
 == Ergebnis Win32API ==

@@ Zeile 7: / Zeile 7: @@
 Eingesetzt habe ich die Boost 1.58 (Stand 18.06.2015).
-<pre>
+<source lang="cpp">
 boost::interprocess::interprocess_mutex      MyMutex;
 boost::interprocess::interprocess_condition  MyCondition;
 boost::interprocess::interprocess_semaphore  MySemaphore;
-</pre>
+</source>
 Dabei habe ich komplette Funktionen mittels scoped_lock gesperrt:
-<pre>
+<source lang="cpp">
 boost::interprocess::scoped_lock<boost::interprocess::interprocess_recursive_mutex> lock(reentrant_block);
-</pre>
+</source>
 Desweiteren habe ich Signale für bestimmte Aktionen über die Condition ausgelösst:
-<pre>
+<source lang="cpp">
 void func1()
+{
@@ Zeile 36: / Zeile 36: @@
    ...
+}
-</pre>
+</source>
 == Ergebnis Boost 1.58==

@@ Zeile 36: / Zeile 36: @@
 </pre>
-=== Ergebnis Boost 1.58===
+== Ergebnis Boost 1.58==
 Der entwickelte Serverprozess hatte eine CPU Last von 2.5%, obwohl dieser im Leerlauf war. Die Last ist einfach nur durch das Warten begrenzt durch einen timeout entstanden.
@@ Zeile 42: / Zeile 42: @@
 Mögliches weiteres Problem: Was bewirkt eine Zeitumstellung bei einem Timeout mit absoluter Zeitangabe?
-== Win32 API ==
+= Win32 API =
 Ich habe alle Stellen ausgetauscht gegen SRWLOCK und CONDITION_VARIABLE, die seit Windows 2008 bzw. Vista unterstützt werden (nicht unter XP oder W2003 bzw. älter). Der neue Code ist fast identisch zu dem Alten.
@@ Zeile 84: / Zeile 84: @@
 </pre>
-=== Ergebnis Win32API ===
+== Ergebnis Win32API ==
 Die Last des Servers im Leerlauf ist auf unter 0.01% gesunken.