我正在使用此代码阻止我的程序的第二个实例同时运行,是否安全？
Mutex appSingleton = new System.Threading.Mutex(false, "MyAppSingleInstnceMutx");
if (appSingleton.WaitOne(0, false)) {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainForm());
appSingleton.Close();
} else {
MessageBox.Show("Sorry, only one instance of MyApp is allowed.");
}
我担心如果有什么东西抛出一个异常并且应用程序崩溃了Mutex仍然会被保留.真的吗？
我见过有些人讨厌recursive_mutex:
http://www.zaval.org/resources/library/butenhof1.html
但是在考虑如何实现一个线程安全的类(互斥保护)时,我觉得很难证明每个应该受互斥保护的方法都是互斥保护的,并且互斥锁最多被锁定一次.
因此,对于面向对象的设计,应该std::recursive_mutex是默认的并且std::mutex在一般情况下被视为性能优化,除非它仅在一个地方使用(仅保护一个资源)？
为了说清楚,我说的是一个私人非静态互斥体.因此每个类实例只有一个互斥锁.
在每个公共方法的开头:
{
std::scoped_lock<std::recursive_mutex> sl;
我将使用boost::mutex从boost/thread/mutex.hpp.有几种方法来锁定/解锁互斥:有scoped_lock,unique_lock,lock_guard,互斥的成员函数::lock()和::unlock()和非成员函数lock()和unlock().
我注意到,这boost::scoped_mutex是使用互斥锁的最流行的方法之一.为什么是最好的成员函数::lock()和::unlock()？
特别是,我为什么要使用
{
boost::scoped_lock lock(mutex)
// ...
// read/output sharing memory.
// ...
}
而不是
mutex.lock()
// ...
// read/output sharing memory.
// ...
mutex.unlock()
是scoped_lock因为某些样式编码的观点还是::lock()/::unlock()"线程安全不够" 而更好？
我很想知道如何在Unix中实现与线程之间的同步相关的函数.例如,当我打电话时会发生什么pthread_mutex_lock？有没有使用指针？对源代码的引用确实会有所帮助.
我有一个具有状态(一个简单的枚举)的类,可以从两个线程访问.为了改变状态,我使用互斥锁(boost :: mutex).检查状态是否安全(例如比较state_ == ESTABLISHED)还是在这种情况下我是否必须使用互斥锁？换句话说,当我只想读取一个可以由另一个线程同时写入的变量时,我是否需要互斥锁？
我和同事为在x86,x64,Itanium,PowerPC和其他10年历史的服务器CPU上运行的各种平台编写软件.
我们刚刚讨论了pthread_mutex_lock()... pthread_mutex_unlock()等互斥函数本身是否足够,或者受保护变量是否需要是volatile.
int foo::bar()
{
//...
//code which may or may not access _protected.
pthread_mutex_lock(m);
int ret = _protected;
pthread_mutex_unlock(m);
return ret;
}
我担心的是缓存.编译器是否可以在堆栈或寄存器中放置_protected的副本,并在赋值中使用该陈旧值？如果没有,是什么阻止了这种情况发生？这种模式的变化是否易受攻击？
我假设编译器实际上并不理解pthread_mutex_lock()是一个特殊函数,所以我们只是受序列点保护吗？
非常感谢.
更新:好的,我可以看到一个趋势,答案解释了为什么不稳定是坏的.我尊重这些答案,但有关该主题的文章很容易在网上找到.我在网上找不到的,以及我问这个问题的原因,就是我如何保护我没有不稳定.如果上面的代码是正确的,那么缓存问题如何无懈可击？
我pthread_cond_wait(&cond_t, &mutex);在我的程序中使用,我想知道为什么这个函数需要作为第二个参数mutex变量.
是否pthread_cond_wait()在开始时解锁互斥锁(执行开始pthread_cond_wait())然后在完成时(就在离开之前pthread_cond_wait())锁定？
这是我到目前为止实现的代码,用于创建单个实例WPF应用程序:
#region Using Directives
using System;
using System.Globalization;
using System.Reflection;
using System.Threading;
using System.Windows;
using System.Windows.Interop;
#endregion
namespace MyWPF
{
public partial class MainApplication : Application, IDisposable
{
#region Members
private Int32 m_Message;
private Mutex m_Mutex;
#endregion
#region Methods: Functions
private IntPtr HandleMessages(IntPtr handle, Int32 message, IntPtr wParameter, IntPtr lParameter, ref Boolean handled)
{
if (message == m_Message)
{
if (MainWindow.WindowState == WindowState.Minimized)
MainWindow.WindowState = WindowState.Normal;
Boolean topmost = MainWindow.Topmost;
MainWindow.Topmost = true;
MainWindow.Topmost = topmost;
}
return IntPtr.Zero;
} …一般来说,pthread_cond_wait()并且pthread_cond_signal()如以下称为:
//thread 1:
pthread_mutex_lock(&mutex);
pthread_cond_wait(&cond, &mutex);
do_something()
pthread_mutex_unlock(&mutex);
//thread 2:
pthread_mutex_lock(&mutex);
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);
步骤是
pthread_cond_wait(&cond, &mutex); 被称为,它解锁互斥锁
线程2锁定互斥锁和调用pthread_cond_signal(),从而解锁互斥锁
在线程1中,pthread_cond_wait()调用并再次锁定互斥锁
现在在线程2中,在pthread_cond_signal()调用之后, pthread_mutex_unlock(&mutex)将要运行,在我看来,它想要解锁现在被线程1锁定的互斥锁.我的理解是否有任何错误？
此外,在我看来,pthread_cond_wait()对于相同的cond-mutex对,只能由1个线程调用.但是有一种说法"pthread_cond_signal()函数应该解除阻塞在指定条件变量cond上阻塞的至少一个线程(如果在cond上阻塞了任何线程)." 那么,pthread_cond_wait()对于相同的cond-mutex对,它是否可以被许多线程调用？