更安全的锁定支持 [英] Safer locking support

问题描述

使用锁定（这个）已经受到很多诽谤，因为你的对象外部有人可以锁定导致可能的死锁并迫使你现在创建一个额外的

对象lock_ = new object（）;在没有更好的锁定的任何类中

来锁定。


如何在System.Object上支持受保护的属性作为SyncObj（所以它

实际上是一个内部锁定对象而不是这个对象）或类似的东西

可以锁定。也许C＃可以更改为支持

以下内容：


lock

{

/ / ...


}


如果没有锁定参数，默认情况下会使用受保护的SyncObj。

这将使C＃.NET线程更安全，更容易。

Using lock(this) has been much maligned since someone external to your object
can lock causing possible deadlock and forcing you to now create an extra
object lock_=new object(); in any classes using locking with nothing better
to lock on.

How about supporting a protected property on System.Object as SyncObj (so it
is really an internal locking object rather than this object) or something
like that that can be locked on. Perhaps the C# can be changed to support
the following:

lock
{
//...

}

With no arguments to lock it would by default use the protected SyncObj.
This will make C#.NET threading safer and easier.

推荐答案

>如何在System.Object上支持受保护的属性SyncObj（所以它

>How about supporting a protected property on System.Object as SyncObj (so it

实际上是一个内部锁定对象而不是这个对象）或类似可以锁定的东西。

is really an internal locking object rather than this object) or something
like that that can be locked on.

我认为那将是一个实例成员，因为否则所有

类都会锁定同一个对象。如果它是一个实例成员，

如果你不需要任何锁定支持，每个对象现在必须支付额外对象引用的费用，甚至

。多么浪费。


我不明白为什么这比我们今天做的更好，

明确声明要锁定的对象。

Mattias


-

Mattias Sj？gren [C＃MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com

请回复到新闻组。

I assume that would be an instance member then, since otherwise all
classes would lock on the same object. If it''s an instance member,
every object now has to pay the cost of an extra object reference even
if you don''t need any locking support. What a waste.

I don''t see why this would be any better than what we do today with
explicitly declaring the object to lock on.
Mattias

--
Mattias Sj?gren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

WXS< WX*@discussions.microsoft.com>写道：

WXS <WX*@discussions.microsoft.com> wrote:

使用锁定（这个）已经受到很多诽谤，因为你的对象外部的人可以锁定导致可能的死锁并迫使你现在创建一个额外的
对象lock_ = new宾语（）;在没有更好的锁定的任何类中锁定。

如何在System.Object上支持受保护的属性作为SyncObj（所以它确实是一个内部锁定对象而不是比这个对象）或类似的东西可以锁定。也许C＃可以改为支持
以下内容：

{
// ...

}
如果没有锁定参数，默认情况下会使用受保护的SyncObj。
这将使C＃.NET线程更安全，更容易。

Using lock(this) has been much maligned since someone external to your object
can lock causing possible deadlock and forcing you to now create an extra
object lock_=new object(); in any classes using locking with nothing better
to lock on.

How about supporting a protected property on System.Object as SyncObj (so it
is really an internal locking object rather than this object) or something
like that that can be locked on. Perhaps the C# can be changed to support
the following:

lock
{
//...

}

With no arguments to lock it would by default use the protected SyncObj.
This will make C#.NET threading safer and easier.

嗯......不完全确定。我更喜欢明确指定锁定

的想法，按照
http://www.pobox.com/~skeet/csharp/m...e/locking.html


如果您的方案中的SyncObj默认为一个新对象，那么

意味着*每个*对象必须有一个额外的字段，这是一个

考虑到大多数类型不需要

锁定，这是不可接受的高成本IMO。


-

Jon Skeet - < sk *** @ pobox.com>
http：// www。 pobox.com/~skeet 博客： http：//www.msmvps。 com / jon.skeet

如果回复该组，请不要给我发邮件

Hmmm... not entirely sure. I prefer the idea of specifying a lock
explicitly, as per
http://www.pobox.com/~skeet/csharp/m...e/locking.html

If SyncObj in your scheme were to default to a new object, that would
mean that *every* object would have to have an extra field, which is an
unacceptably high cost IMO, considering that most types don''t need
locking.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

作为受保护的实例成员意味着你不需要明确

声明一个ob锁定。如果使用lock（this），编译器可能也是一个好主意

生成警告，因为它确实不安全（尽管

可能是一个有点多）。当然，如果使用

内部机制，可以使用这种方法减少输入，可能是
可以防止内部分配新的真实对象来锁定。如果真的只是想要一个锁定，那么基础对象中可能存在开销，而你只需要b $ b。它也可能打开一些之前很难的b $ b编译器和JIT优化，就像现在

你明确知道什么被锁定之前它必须是

在运行时解释。


只是一些想法...


" Mattias Sj ?? gren"写道：

As a protected instance member this means you don''t need to explicitly
declare a object to lock on. Probably also a good idea for the compiler to
generate a warning if lock(this) is used, since it really isn''t safe (though
that may be a bit much). Certainly less typing with this method, possibly
prevents the need to internally allocate a new real object to lock on if the
internal mechanism is used. There is likely overhead in a base object you
just don''t need if really you just want a lock. It also likely opens up some
compiler and JIT optimizations that would have been difficult before, as now
you know specifically what is being locked where before it had to be
interpreted at runtime.

Just some thoughts...

"Mattias Sj??gren" wrote:

如何在System.Object上支持受保护的属性作为SyncObj（所以它确实是一个内部锁定对象，而不是这个对象）或类似的东西可以锁定。

How about supporting a protected property on System.Object as SyncObj (so it
is really an internal locking object rather than this object) or something
like that that can be locked on.

我认为那将是一个实例成员，因为否则所有
类都会锁定同一个对象。如果它是一个实例成员，
如果你不需要任何锁定支持，现在每个对象都需要支付额外对象引用的费用。真是太浪费了。

我不明白为什么这会比我们今天做的更好，
明确声明要锁定的对象。

Mattias

- Mattias Sj ?? gren [C＃MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
请仅回复新闻组。

I assume that would be an instance member then, since otherwise all
classes would lock on the same object. If it''s an instance member,
every object now has to pay the cost of an extra object reference even
if you don''t need any locking support. What a waste.

I don''t see why this would be any better than what we do today with
explicitly declaring the object to lock on.
Mattias

--
Mattias Sj??gren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

这篇关于更安全的锁定支持的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！