锁定技术 [英] Locking techniques

问题描述

为了同步对共享对象的线程访问，我总是使用

锁（shared_object）{}模式。

我见过很多推荐和同步使用的示例

lock（another_object）{use shared_object;模式。


我没有看到任何理由让另一个简单的对象锁定，因为我可以直接锁定共享对象。

可以直接锁定共享对象。


使用共享锁对象来保护

实际共享对象是否有任何深层含义，可能是性能导向的？

哪个更好，如果它可以衡量吗？

TIA，


LT

To synchronize thread access to shared objects, I''ve always used the
lock(shared_object) { } pattern.
I''ve seen many recommendations and examples where to synchronize use
lock(another_object) { use shared_object; } pattern.

I do not see any reason to have another simple object to lock for since I
can lock the shared object directly.

Are there any deep implications to use shared lock object to guard the
actual shared object, maybe performance oriented?
Which is better, if it can be measured?
TIA,

LT

推荐答案

你好LT，


，因为你的代码控制了谁以及何时将锁应用于此

对象。在第一种情况下，流氓客户端可以获取并保持对shared_object的锁定
，以防止其他线程访问它。


我不是确定CLR内部是否有一些代码可能会影响性能，不知怎的，我不这么认为。但是后者

方法比第一个更多地使用一个对象。


在我看来，如果你正在编写自己的应用程序而且

shared_object是一个私有对象，即没有人可以在外面访问它。

你是代码，那么使用第一种方法你会很好。


简而言之，第二种方法更安全且不易出错，但使用了更多的内存。


干杯，

Adam

--------------------------------- -------------------------------------------------- --------

J-Integra互操作性解决方案
http://j-integra.intrinsyc.com/

用于java，corba，com&的高性能互操作中间件.net

Hi LT,

A recommendation to use the latter approach [lock(another_object)] is
because your code controls who and when locks are applied to to this
object. In the first case, a rogue client may obtain and keep a lock
to the shared_object preventing the other threads from accessing it.

I''m not sure if there is some code deep down in the CLR that would
impact performance and somehow I don''t think so. But the latter
approach uses one more object a little more memory than the first.

In my opinion, if you are writing your own application and the
shared_object is a private object, ie no one can access it outside
you''re code, then you''ll be quite fine using the first approach.

In short, the second approach is safer and less error prone but uses a
bit more memory.

Cheers,
Adam
-------------------------------------------------------------------------------------------
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net

嗨Adam，


对我来说，第一次进场锁（shared_object）似乎比我更好不是

需要查找哪个对象守卫哪个。更容易记住锁定

我需要操作的对象，而不是查找哪个防护对象守卫

什么。并且它会自动锁定更细粒度，因为

another_object也可以（错误地）用于保护其他用途。

如果可能有一些CLR内部，我更担心使得b / b
首次使用效率更低或危险。


谢谢，


LT


" Adam Cooper" <广告********* @ gmail.com> ha scritto nel messaggio

news：11 ********************** @ g49g2000cwa.googlegr oups.com ...

Hi Adam,

For me the first approach lock(shared_object) seemed better since I do not
need to lookup which object guards which. It''s easier to remember to lock
the object I need to operate really than to lookup which guard object guards
what. And it makes locking more granular automatically because the
another_object could be used (wrongly) to guard other uses also.
I was more concerned if there could be some CLR internals that makes the
first apporach more inefficient or "dangerous".

Thanks,

LT

"Adam Cooper" <ad*********@gmail.com> ha scritto nel messaggio
news:11**********************@g49g2000cwa.googlegr oups.com...

你好LT，

使用后一种方法[lock（another_object）]的建议是
因为你的代码控制了谁以及什么时候把锁应用到这个
对象。在第一种情况下，流氓客户端可能会获取并保持对shared_object的锁定，以防止其他线程访问它。

我不确定是否存在一些深层代码在CLR中会影响性能，不知怎的，我不这么认为。但是后一种方法使用了一个比第一个更多的内存。

在我看来，如果你正在编写自己的应用程序，那么
shared_object是一个私有对象，即没有人可以在外面访问
你是代码，那么使用第一种方法你会很好。

简而言之，第二种方法更安全，更少错误容易但是使用了更多的记忆。

干杯，
Adam
------------------- -------------------------------------------------- ----------------------
J-Integra互操作性解决方案
http://j-integra.intrinsyc.com/
高性能的互操作中间件，适用于java，corba，com& .net

Hi LT,

A recommendation to use the latter approach [lock(another_object)] is
because your code controls who and when locks are applied to to this
object. In the first case, a rogue client may obtain and keep a lock
to the shared_object preventing the other threads from accessing it.

I''m not sure if there is some code deep down in the CLR that would
impact performance and somehow I don''t think so. But the latter
approach uses one more object a little more memory than the first.

In my opinion, if you are writing your own application and the
shared_object is a private object, ie no one can access it outside
you''re code, then you''ll be quite fine using the first approach.

In short, the second approach is safer and less error prone but uses a
bit more memory.

Cheers,
Adam
-------------------------------------------------------------------------------------------
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net

" Adam Cooper" <广告********* @ gmail.com>在消息中写道

news：11 ********************** @ g49g2000cwa.googlegr oups.com ...

"Adam Cooper" <ad*********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

你好LT，

使用后一种方法[lock（another_object）]的建议是
因为你的代码控制了谁以及何时将锁应用于此
宾语。在第一种情况下，流氓客户端可能会获取并保持对shared_object的锁定，以防止其他线程访问它。

我不确定是否存在一些深层代码在CLR中会影响性能，不知怎的，我不这么认为。但是后一种方法使用了一个比第一个更多的内存。

在我看来，如果你正在编写自己的应用程序，那么
shared_object是一个私有对象，即没有人可以在外面访问
你是代码，那么使用第一种方法你会很好。

简而言之，第二种方法更安全，更少错误容易但是使用了更多的内存。

干杯，
Adam

Hi LT,

A recommendation to use the latter approach [lock(another_object)] is
because your code controls who and when locks are applied to to this
object. In the first case, a rogue client may obtain and keep a lock
to the shared_object preventing the other threads from accessing it.

I''m not sure if there is some code deep down in the CLR that would
impact performance and somehow I don''t think so. But the latter
approach uses one more object a little more memory than the first.

In my opinion, if you are writing your own application and the
shared_object is a private object, ie no one can access it outside
you''re code, then you''ll be quite fine using the first approach.

In short, the second approach is safer and less error prone but uses a
bit more memory.

Cheers,
Adam

此外，由于单身经常被实施使用静态成员和方法

没有''这个'来锁定。因此，需要锁定物品。


快乐编码

- Michael S

Also, as Singletons are often implemented with static members and methods
there are no ''this'' to lock on. Hence, a lock object are needed.

Happy Coding
- Michael S

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