唯一标识多个/并发异步任务 [英] Uniquely Identifying Multiple/Concurrent Async Tasks
问题描述
System.Random似乎会通过
提供一个可接受的方法来生成一个用于识别多个/并发
异步任务的唯一值。
这里考虑的值的用法是它提供给
AsyncOperationManager.CreateOperation（userSupplied State）方法...
userSuppliedState或多或少是一个taskId。
在这种情况下，userSuppliedState {really taskId}属于对象类型，
因此可能因此几乎任何东西。因此，在我看来
，System.Random生成的唯一整数就足够了（是的，
我明白System.Random并不能提供真正的* *随机值）。
您是否同意System.Random将足够好？ - 或者你会为
推荐一些更好的替代方案来生成taskId吗？
谢谢！
Frankie，
如果你真的需要一些非常有保证的东西（但不是完全的b / b），那就是随机的，独特的，然后我建议你使用Guid
实例。在你真正创建副本之前，你必须以接下来的十亿美元/秒
5000 /秒之类的速度生成新的Guids，或者像你那样荒谬地生成一个副本。< br $> b $ b -
- Nicholas Paldino [.NET / C＃MVP]
- mv*@spam.guard.caspershouse.com
" Frankie" < A@B.COMwrote in message
news：％2 **************** @ TK2MSFTNGP03.phx.gbl ...
看来System.Random会通过
提供一个可接受的方法来生成一个用于识别多个/并发的唯一值
异步任务。
这里考虑的值的用法是它提供给AsyncOperationManager.CreateOperation（userSupplied State）方法的
.. 。$ / b $ b，userSuppliedState或多或少是一个taskId。
在这种情况下，userSuppliedState {really taskId}是对象类型，
因此可能几乎任何事情。因此在我看来
由System.Random生成的唯一整数就足够了（并且
是的，我明白System.Random并不能提供真正的* *随机
值）。
你是否同意System.Random将足够好？ - 或者你会为
推荐一些更好的替代方案来生成taskId吗？
谢谢！
Frankie写道：
似乎System.Random将通过
提供可接受的方式来生成用于标识多个/并发
异步任务的唯一值。
Nope。
这里考虑的值的用法是它被提供给
AsyncOperationManager.CreateOperation（userSupplied State）方法...
userSuppliedState或多或少是一个taskId。
你如何将它用作身份证？你能提供一个更具体的例子吗？
在这种情况下，userSuppliedState {really taskId}属于对象类型，
并且可以因此几乎可以做任何事情。因此，在我看来
，System.Random生成的唯一整数就足够了（是的，
我明白System.Random并不能提供真正的* *随机值）。
它可以是任何东西。通常情况下，它会是一个类，b $ b存储对任务实例很重要的上下文。
你是否同意System.Random将是& ;足够好 - 或者你会为b
推荐一些更好的替代方案来生成taskId吗？
不，这太可怕了。随机数不保证是唯一的。
如果每个任务都需要某种独特的上下文，为什么不创建一个可以包含的
类在这个上下文中，存储与类中的
上下文相关的数据，并使用对该类的引用为您的唯一
值？
如果你真的只需要一个整数，为什么不使用顺序
数？如果你有可能随着时间的推移创造4亿个任务，那么你需要检查新生成的数字，以确保它们不会被使用，但是如果你还在使用Random，那将是一个要求，
，因为那些并不是唯一的。
Pete
< snip>
Re：
<<如果每项任务都需要某种独特的背景，......
我不确定你所说的背景是什么意思。这里......我指的是
，任务只需要一个独特的_identifier_。我正在做的是实现基于事件的异步模式的
。因此，在这种情况下，我有一个异步
操作 - 可以进行多个并发操作。
例如，它是一个名为GrabFileAsync的方法，它检索一个文件
来自某个偏远地区的
。客户端可以请求15个不同的文件 - 所以
我们将有15个GrabFileAsync（）调用 - 可能所有15个同时运行
。这15个并发操作中的每一个都需要唯一确定的b
。客户端在调用GrabFileAsync（）后将提供
唯一标识符。当15个异步操作中的任何一个完成或报告
进度等时，客户端将使用任务ID。识别哪个特定的GrabFileAsync（）操作已经完成等等。
完全有可能你的意思是上下文。和我的相似。
如果是这样的话，也许你可以澄清为什么整数不是最好的，为什么要用一些上下文来表示
上课会更好。如果没有，你是否在想
SynchronizationContext或类似的东西？如果是这样，那么你就会失踪
事实上AsyncOperation - 这是基于事件的异步
模式实现的一部分我将要 - 基本上封装了
底层的SynchronizationContext ....因此不需要我提供
SynchronizationContext。
-F
It appears that System.Random would provide an acceptable means through
which to generate a unique value used to identify multiple/concurrent
asynchronous tasks.
The usage of the value under consideration here is that it is supplied to
the AsyncOperationManager.CreateOperation(userSupplied State) method... with
userSuppliedState being, more or less, a taskId.
In this case, the userSuppliedState {really taskId} is of the object type,
and could therefore be just about anything. Consequently it appears to me
that a unique integer as generated by System.Random would suffice (and yes,
I understand that System.Random doesn''t provide *truly* random values).
Would you concur that System.Random would be "good enough" - or would you
recommend some better alternative for generating the taskId?
Thanks!
Frankie,
If you really need something that is pretty much guaranteed (but not
completely) to be random, and unique, then I suggest you use a Guid
instance. You would have to generate new Guids at a rate of something like
5000/second for the next billion years or something ridiculous like that
before you actually create a duplicate.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Frankie" <A@B.COMwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...It appears that System.Random would provide an acceptable means through
which to generate a unique value used to identify multiple/concurrent
asynchronous tasks.
The usage of the value under consideration here is that it is supplied to
the AsyncOperationManager.CreateOperation(userSupplied State) method...
with userSuppliedState being, more or less, a taskId.
In this case, the userSuppliedState {really taskId} is of the object type,
and could therefore be just about anything. Consequently it appears to me
that a unique integer as generated by System.Random would suffice (and
yes, I understand that System.Random doesn''t provide *truly* random
values).
Would you concur that System.Random would be "good enough" - or would you
recommend some better alternative for generating the taskId?
Thanks!
Frankie wrote:It appears that System.Random would provide an acceptable means through
which to generate a unique value used to identify multiple/concurrent
asynchronous tasks.Nope.
The usage of the value under consideration here is that it is supplied to
the AsyncOperationManager.CreateOperation(userSupplied State) method... with
userSuppliedState being, more or less, a taskId.How are you using it as an ID? Can you provide a more concrete example?
In this case, the userSuppliedState {really taskId} is of the object type,
and could therefore be just about anything. Consequently it appears to me
that a unique integer as generated by System.Random would suffice (and yes,
I understand that System.Random doesn''t provide *truly* random values).It can be just about anything. Typically, it would be a class that
stores context important to the task instance.
Would you concur that System.Random would be "good enough" - or would you
recommend some better alternative for generating the taskId?No, it would be awful. Random numbers aren''t guaranteed to be unique.
If each task requires some sort of unique context, why not just create a
class that can contain this context, store the data related to the
context in the class, and use a reference to the class a your "unique
value"?
If you really just need an integer, why not just use a sequential
number? If you could potentially create 4 billions tasks over time,
you''ll have to check newly generated numbers to make sure they aren''t in
use, but that would be a requirement if you''re using Random anyway,
since those aren''t guaranteed to be unique.
Pete
<snip>
Re:
<< If each task requires some sort of unique context,..."
I''m not sure what you mean by "context" here... what I''m referring to is
that the task just needs a unique _identifier_. What I''m doing is
implementing the Event-based async pattern. So in this case I have an async
operation - for which there can be multiple concurrent operations going on.
For example, it cold be a method named GrabFileAsync that retrieves a file
from some remote location. The client could request 15 different files - so
we''d have 15 GrabFileAsync() calls - with potentially all 15 of them running
concurrently. Each of these 15 concurrent operations needs to be uniquely
identified. The client, upon calling GrabFileAsync() would then supply a
unique identifier. When any of the 15 async operations completes or reports
progress, etc, the client would then use the "task id" to identify which
particular GrabFileAsync() operation has completed, etc.
It''s entirely possible that your meaning "context" is the similar to mine.
If so, maybe you could clarify why an integer isn''t the best, and why going
with some "context" class would be better. If not, are you thinking
SynchronizationContext or something like that? If so, then you''d be missing
the fact that the AsyncOperation - which is part of the Event-based async
pattern implementation I''m going with - basically encapsulates the
underlying SynchronizationContext.... so therefore no need for me to supply
SynchronizationContext.
-F
这篇关于唯一标识多个/并发异步任务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
