The essential problems in multithreaded programming

When writing multithreaded program, we often need to judge the critical conditions, such as the number of available objects in the pool, the availability of an object, and so on. When we do this, we are wrong. Why do you say that? Because in our subconscious we have been using absolute time points to determine multithreaded programs. Because we habitually use the lock and then determine the current point of the critical condition of the state and make the corresponding processing. Of course you can. But the idea is wrong, the lock is for synchronizing resources rather than critical conditions ( Of course you do, but I'm longing for a lock-free concurrency. So what can we rely on when we don't depend on absolute time? That is the event, but this event is not the keyword in. net. This is a logical concept. Events in multiple threads are meant to happen. For example, to use objects in the object pool , this is an event. Then it will happen instead of relying on the current available number, because the moment you read it can be used but it may not be available at the time of the call (of course you can use a lock, but the efficiency of the lock is very low and will deadlock). So what exactly are we going to do with this? Use semaphore in most cases (sometimes you can use interlocked to see what I do with the 2 critical conditions in my "implement one semaphore"). It's easy to say, We change the judgment of the specific condition to the semaphore object's wait. This does not appear to be an ugly code that is handled with While+sleep when the critical condition is not satisfied.

In my programming system I gave Semaphore an alias called the Event_trigger event trigger. Its purpose is to control whether an event can be set off. For example, producing a consumer model in multithreaded programming is one of the most typical The most commonly used model. So we generally implement a production consumption queue. This queue is very simple that the producer puts the produced film into the queue and the consumer takes away the consumption from the queue. The most intuitive example in daily life is the bakery, The pie maker put the cake on the counter for everyone to buy. This is the queue at the counter, and there's a problem. What if the counter is full? We might say that queue can grow dynamically, but memory is limited. We cannot allow the queue to grow indefinitely. So we need two critical conditions: The maximum number of queue and whether it can be consumed for control. But what we're actually asking for is two events, production events and consumption events that are blocked if the event doesn't happen.

Let's take a look at how to use the mechanism of the event to write this queue, which I personally think is better and more straightforward than judging the absolute point of time (because the queue is very simple and I only give the key snippets).

Event_Trigger　produce; //最小可用0,最大数为int.max
Event_Trigger _consume; //同上
public void Push(Item i) //生产
{
_produce.Wait();　//等待生产事件发生
queue.Enqueue(i);
_consume.Post();　//通知消费事件发生
}

Use _consume in pop methods. Wait (), _produce. Post ().

This is not very concise, very intuitive. I was listening to my boss after the explanation is really a sobering feeling, the top of the pile may not be expressed clearly, but I strongly think you recommend this use of events instead of critical conditions to judge the way.