本文翻译自:C# version of java's synchronized keyword?
Does c# have its own version of the java "synchronized" keyword? c#是否具有自己的java“ synchronized”关键字版本?
Ie in java it can be specified either to a function, an object or a block of code, like so: 即在Java中,可以将其指定为函数,对象或代码块,如下所示:
public synchronized void doImportantStuff() {
// dangerous code goes here.
}
or 要么
public void doImportantStuff() {
// trivial stuff
synchronized(someLock) {
// dangerous code goes here.
}
}
#1楼
参考:https://stackoom.com/question/2Gmw/Java同步关键字的C-版本
#2楼
请注意,在完整路径下,该行: [MethodImpl(MethodImplOptions.Synchronized)]
应该看起来像
[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.Synchronized)]
#3楼
Does c# have its own version of the java "synchronized" keyword? c#是否具有自己的java“ synchronized”关键字版本?
No. In C#, you explicitly lock
resources that you want to work on synchronously across asynchronous threads. 否。在C#中,您显式lock
了要跨异步线程同步处理的资源。 lock
opens a block; lock
打开一个块; it doesn't work on method level. 它在方法级别上不起作用。
However, the underlying mechanism is similar since lock
works by invoking Monitor.Enter
(and subsequently Monitor.Exit
) on the runtime. 但是,底层机制是相似的,因为lock
是通过在运行时调用Monitor.Enter
(然后是Monitor.Exit
)来实现的。 Java works the same way, according to the Sun documentation . 根据Sun文档 ,Java的工作方式相同。
#4楼
static object Lock = new object();
lock (Lock)
{
// do stuff
}
#5楼
You can use the lock
statement instead. 您可以改用lock
语句。 I think this can only replace the second version. 我认为这只能替代第二个版本。 Also, remember that both synchronized
and lock
need to operate on an object. 另外,请记住, synchronized
和lock
需要对一个对象进行操作。
#6楼
First - most classes will never need to be thread-safe. 首先-大多数类将永远不需要是线程安全的。 Use YAGNI : only apply thread-safety when you know you actually are going to use it (and test it). 使用YAGNI :仅当您知道实际上将要使用它(并对其进行测试)时,才应用线程安全性。
For the method-level stuff, there is [MethodImpl]
: 对于方法级的东西,有[MethodImpl]
:
[MethodImpl(MethodImplOptions.Synchronized)]
public void SomeMethod() {/* code */}
This can also be used on accessors (properties and events): 这也可以用于访问器(属性和事件):
private int i;
public int SomeProperty
{
[MethodImpl(MethodImplOptions.Synchronized)]
get { return i; }
[MethodImpl(MethodImplOptions.Synchronized)]
set { i = value; }
}
Note that field-like events are synchronized by default, while auto-implemented properties are not : 请注意,默认情况下,类似字段的事件是同步的,而自动实现的属性则不是 :
public int SomeProperty {get;set;} // not synchronized
public event EventHandler SomeEvent; // synchronized
Personally, I don't like the implementation of MethodImpl
as it locks this
or typeof(Foo)
- which is against best practice. 就我个人而言,我不喜欢MethodImpl
的实现,因为它会锁定this
或typeof(Foo)
-这违反了最佳实践。 The preferred option is to use your own locks: 首选选项是使用您自己的锁:
private readonly object syncLock = new object();
public void SomeMethod() {
lock(syncLock) { /* code */ }
}
Note that for field-like events, the locking implementation is dependent on the compiler; 注意,对于类似字段的事件,锁定实现取决于编译器。 in older Microsoft compilers it is a lock(this)
/ lock(Type)
- however, in more recent compilers it uses Interlocked
updates - so thread-safe without the nasty parts. 在较旧的Microsoft编译器中,它是一个lock(this)
/ lock(Type)
-但是, 在较新的编译器中,它使用Interlocked
更新-线程安全,没有讨厌的部分。
This allows more granular usage, and allows use of Monitor.Wait
/ Monitor.Pulse
etc to communicate between threads. 这允许更精细的使用,并允许使用Monitor.Wait
/ Monitor.Pulse
等在线程之间进行通信。
A related blog entry (later revisited ). 相关的博客条目 (后来重新访问 )。