如何使用参数处理多个线程。请参阅说明以获取更多信息。 [英] How to handle multiple threads with parameters. please see description for more information.

问题描述

我们有4个或更多线程。线程数不固定。每个线程都会使用一些参数调用相同的web服务。



public void WSCall（bool flag）

{



//我们需要标志值仅对单线程为真。

//休息3个帖子应该有错误的标志值。

//这里叫服务。

}



我尝试了什么：



我们尝试使用锁，但我们不想锁因为它进行同步调用。

We have 4 or more threads. Number of thread is not fixed. Each thread will call the same webservice with some parameter.

public void WSCall(bool flag)
{

//We need flag value to be true only for single thread. The
//rest 3 threads should have false value of the flag.
//call to service here.
}

What I have tried:

We tried using lock, but we dont want lock as it makes sync call.

推荐答案

首先，我强烈建议在运行时超出静态设置限制时避免增加线程数。我理解一个线程可以解决其语义上孤立的问题，但是太多线程会严重影响整体系统性能，只有当你有足够的CPU /核心时才会增长，然后每个线程的创建和支持的开销开始占主导地位，甚至虽然操作系统的线程切换非常快。如果线程数有可能根据运行时环境而显着增长，则必须检查您的体系结构。



现在，您要问两个与线程无关的问题通信。首先，传递一个参数。我根据我提出的设计元素描述了我使用的方法，以支持与线程通信的不同目的，首先，它的初始化;我称之为线程包装器：

如何将ref参数传递给线程 [ ^ ]，

更改线程（生产者）启动后的参数 [ ^ ]，

C＃中的MultiThreading [ ^ ];

参见：

使代码线程安全 [ ^ ]，

AsyncCallback和Threadings [ ^ ]。



如您所见，我还解释了如何通过线程包装器在线程之间使用线程同步。您可以学习或了解的第一件事是线程同步，例如常规 lock ，关键部分（互斥（更一般地说）），事件等待句柄等等。您提出了一个特殊问题：在一组线程之间支持一些逻辑不变。我们来讨论它。



首先，因为你的不变量（每组线程只有一个标志）应该覆盖整个一些线程集，应该是另一个线程它起着这种旗帜分配机制的中央仲裁员的作用。这是否是您的应用程序的初始主题并不重要。您需要了解该标志不能从一个线程中取出并同时提供给另一个线程。因此，这将是不保持不变量的一段时间。因此，您需要进行此操作 原子 ，在您的情况下，操作任何线程在逻辑上都不会受到这段时间的影响，也就是说，在这段时间内，没有任何线程可以执行任何会影响使用此标志的机制的操作。换句话说，理想情况下，所有线程都可以冻结，直到传递标志的操作尚未完成。实际上，您只能在标记传递期间暂停某些特定活动。我认为在某些共享资源上进行适当的锁定或锁定是非常明显的，但是，如果您不太清楚，我们可以讨论它，但只有在您解释标志的使用时，才能避免描述太多假设情景。 br />


也就是说，你必须用一个标志执行一些应用于所有线程的锁定。 （顺便说一句，您可以轻松地将标志本身存储在一个线程中，而不是在该中央仲裁器对象中;逻辑很简单：如果您需要中央仲裁，则更容易简单地保持指向一个选择的指针线程，但是这个操作无论如何都应该是原子的。对于所选择的线程，它只能接收通知。）



这使整个想法变得可疑。过度使用线程同步很容易破坏线程的目的。您可能需要检查您的架构。



良好的线程架构使用一个重要原则：最佳线程同步不同步。

-SA

First of all, I would strongly recommend to avoid growing number of thread during runtime beyond statically set limit. I understand that a thread can solve its semantically isolated problems, but too many threads can seriously compromise overall system performance, which grows only while you have enough CPUs/cores, and then the overhead of creation and support of each thread starts to dominate, even though the thread switching by the OS is quite fast. If there is a chance that the number of thread considerably grows depending on runtime environment, you have to review your architecture.

Now, you are asking two unrelated questions about thread communications. First, passing a parameter. I described the approach I used based on the design element I put forward for support of different purposes of communication with a thread, and, first, its initialization; I call it thread wrapper:
How to pass ref parameter to the thread[^],
Change parameters of thread (producer) after it is started[^],
MultiThreading in C#[^];
see also:
Making Code Thread Safe[^],
AsyncCallback and Threadings[^].

As you can see, I also explained how to use thread synchronization between thread through the thread wrapper. The first thing you can learn or know well is thread synchronization, such as regular lock, critical sections (mutually exclusion, more generally), event wait handles, and so on. You formulate one special problem: support of some logical invariant between a set of thread. Let's discuss it.

First of all, as your invariant (only one flag per set of threads) should cover the whole set of some threads, should be one more thread which plays the role of a central arbitrator of the mechanism of such "flag distribution". It does not matter if this is the initial thread of your application or not. You need to understand that the flag cannot be taken off one thread and given to another thread at the same time. Therefore, it will be a period of time when your invariant is not maintained. So, you need to make this operation atomic, which, in your case, the operation of any thread is not affected by this period of time logically, that is, none of the thread could perform any operation which would affect your mechanism using this flag, during this period of time. In other words, ideally, all threads could be "frozen" until the operation of passing a flag is not yet complete. In practice, you can only pause some specific activity during the flag passing. I think appropriate locking or locking at some shared resource is pretty obvious, but, if it's not quite clear to you, we can discuss it, but only if you explain the use of the flag, to avoid describing of too many hypothetical scenarios.

That said, you have to perform some locking applied to all the thread with a flag. (By the way, you can easily store the flag itself not even in a thread, but in that central arbitrator object instead; the logic is simple: if you need central arbitration, it's easier to simply keep a pointer to one single "chosen" thread, but this operation should be atomic anyway. As to the chosen thread, it can just receive the notification.)

And that makes the whole idea suspicious. Overusing of thread synchronization can easily defeat the purpose of threading. It's possible that you need to review your architecture.

Good threading architecture uses one important principle: best thread synchronization is no synchronization.

—SA

这篇关于如何使用参数处理多个线程。请参阅说明以获取更多信息。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！