<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[boost, locking und zwei kritische Ressourcen]]></title><description><![CDATA[<p>Hallo,</p>
<p>ich bin neu im Threading-Thema. Ich versuche, zwei kritische Ressourcen gleichzeitig zu locken. Klappt denke ich ganz gut. Dann wird ein weiterer Funktionsaufruf getätigt, in welchem wiederrum ein Lock auf dieselbe Ressource gemacht wird. Resultat ist meines logischen Verständnisses nach ein Deadlock.</p>
<p>Beispiel</p>
<pre><code>int TcpHook::closesocket(SOCKET socket)
{
	int result = closesocketOriginal_(socket);

	// Richtig so, dass der Lock erst danach beantragt wird?
	// Oder gibt es eine Best Practice, dass der Lock ganz oben in der Funktion steht?
	boost::lock(mutexChannels_, mutexSockets_);
	boost::lock_guard&lt;boost::mutex&gt; guard(mutexChannels_, boost::adopt_lock_t());
	boost::lock_guard&lt;boost::mutex&gt; guard2(mutexSockets_, boost::adopt_lock_t());

	// Beantragt wiederrum einen lock auf mutexSockets_
	// Müsste ich also einen Recursive Lock verwenden?
	// Aber genau genommen ist es ja keine Rekursion.
	TcpChannel *channel = GetChannelForSocket(socket);

	if (channel != nullptr)
	{
		sockets_.erase(socket);
		channel-&gt;OnDisconnect(socket);
	}

	return result;
}
</code></pre>
<p>Die essentiellen Fragen sind als Kommentare im Code-Beispiel.</p>
<p>Dazu habe ich noch eine weitere Frage. Werden Locks nur im kleinsten Rahmen auf die wirklich kritische Ressource gehalten, oder sollte der Lock so lange bestehen bleiben, wie er semantisch sinnvoll ist? Beispiel: Ich hole mir einen Pointer aus einer <code>std::map</code> und mache einen Lock um den Vorgang des Abrufens. Danach muss ich den Pointer aber noch verwenden. Ist es nun &quot;richtiger&quot;, den Lock bis nach der letzten Verwendung des Pointers aufrechtzuhalten? Ich denke ja, da ansonsten ein anderer Thread das Objekt, auf dass der Pointer zeigt, zerstören könnte.</p>
<p>Ich danke euch schon mal!</p>
]]></description><link>https://www.c-plusplus.net/forum/topic/326654/boost-locking-und-zwei-kritische-ressourcen</link><generator>RSS for Node</generator><lastBuildDate>Sun, 31 May 2026 10:57:22 GMT</lastBuildDate><atom:link href="https://www.c-plusplus.net/forum/topic/326654.rss" rel="self" type="application/rss+xml"/><pubDate>Sun, 29 Jun 2014 11:25:10 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to boost, locking und zwei kritische Ressourcen on Sun, 29 Jun 2014 11:25:10 GMT]]></title><description><![CDATA[<p>Hallo,</p>
<p>ich bin neu im Threading-Thema. Ich versuche, zwei kritische Ressourcen gleichzeitig zu locken. Klappt denke ich ganz gut. Dann wird ein weiterer Funktionsaufruf getätigt, in welchem wiederrum ein Lock auf dieselbe Ressource gemacht wird. Resultat ist meines logischen Verständnisses nach ein Deadlock.</p>
<p>Beispiel</p>
<pre><code>int TcpHook::closesocket(SOCKET socket)
{
	int result = closesocketOriginal_(socket);

	// Richtig so, dass der Lock erst danach beantragt wird?
	// Oder gibt es eine Best Practice, dass der Lock ganz oben in der Funktion steht?
	boost::lock(mutexChannels_, mutexSockets_);
	boost::lock_guard&lt;boost::mutex&gt; guard(mutexChannels_, boost::adopt_lock_t());
	boost::lock_guard&lt;boost::mutex&gt; guard2(mutexSockets_, boost::adopt_lock_t());

	// Beantragt wiederrum einen lock auf mutexSockets_
	// Müsste ich also einen Recursive Lock verwenden?
	// Aber genau genommen ist es ja keine Rekursion.
	TcpChannel *channel = GetChannelForSocket(socket);

	if (channel != nullptr)
	{
		sockets_.erase(socket);
		channel-&gt;OnDisconnect(socket);
	}

	return result;
}
</code></pre>
<p>Die essentiellen Fragen sind als Kommentare im Code-Beispiel.</p>
<p>Dazu habe ich noch eine weitere Frage. Werden Locks nur im kleinsten Rahmen auf die wirklich kritische Ressource gehalten, oder sollte der Lock so lange bestehen bleiben, wie er semantisch sinnvoll ist? Beispiel: Ich hole mir einen Pointer aus einer <code>std::map</code> und mache einen Lock um den Vorgang des Abrufens. Danach muss ich den Pointer aber noch verwenden. Ist es nun &quot;richtiger&quot;, den Lock bis nach der letzten Verwendung des Pointers aufrechtzuhalten? Ich denke ja, da ansonsten ein anderer Thread das Objekt, auf dass der Pointer zeigt, zerstören könnte.</p>
<p>Ich danke euch schon mal!</p>
]]></description><link>https://www.c-plusplus.net/forum/post/2406166</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/2406166</guid><dc:creator><![CDATA[theliquidwave]]></dc:creator><pubDate>Sun, 29 Jun 2014 11:25:10 GMT</pubDate></item><item><title><![CDATA[Reply to boost, locking und zwei kritische Ressourcen on Sun, 29 Jun 2014 13:25:29 GMT]]></title><description><![CDATA[<p>theliquidwave schrieb:</p>
<blockquote>
<p>Dann wird ein weiterer Funktionsaufruf getätigt, in welchem wiederrum ein Lock auf dieselbe Ressource gemacht wird. Resultat ist meines logischen Verständnisses nach ein Deadlock.</p>
</blockquote>
<p>Steht in der Beschreibung von mutex.<br />
Die sind gerne auch mal so definiert, daß man innerhalb desselben Threads ruhig öfter locken darf, damit man genau das machen kann, was Du machst. Es müssen ja nur fremde Threads blocken, die auf dieselbe Ressource zugreifen wollen, die Du Dir schon geschnappt hast.</p>
]]></description><link>https://www.c-plusplus.net/forum/post/2406192</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/2406192</guid><dc:creator><![CDATA[volkard]]></dc:creator><pubDate>Sun, 29 Jun 2014 13:25:29 GMT</pubDate></item><item><title><![CDATA[Reply to boost, locking und zwei kritische Ressourcen on Sun, 29 Jun 2014 13:27:24 GMT]]></title><description><![CDATA[<p>Du musst jedes geteilte Byte schützen.<br />
Rekursive Sperren haben nichts mit rekursiven Funktionen zu tun.</p>
<p>Warum werden Sockets geteilt? Das ist sehr fragwürdig!</p>
<p>Mit deinen Funktionen kann ein Socket mehrfach und von verschiedenen Threads freigegeben werden. Ebenfalls fragwürdig.</p>
]]></description><link>https://www.c-plusplus.net/forum/post/2406193</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/2406193</guid><dc:creator><![CDATA[manni66]]></dc:creator><pubDate>Sun, 29 Jun 2014 13:27:24 GMT</pubDate></item></channel></rss>