Linux parent Linus: Object reference count must be atomic

Linus the great God again in rant! This time the Spit object is the hot parallel technology (parellism), and it is straightforward to say that parallel computing is a waste of all time ("the whole" let's parallelize "thing is a huge waste Of everybody ' s time. '). The general meaning is to say that disorderly order performance is fast, increase cache capacity, reduce power consumption. Of course, I do not intend to discuss the parallel issues of right and wrong (too grand theme), because Linus in another post to the object reference count (reference counting) examples to illustrate the complexity of parallelism.

In the case of a Linus reply, it was pointed out that the object needed a lock mechanism, the atomic problem of reference count:

Since it is being accessed in a multi-threaded way, via multiple access paths, generally it needs its own Mutex-otherwis E, reference counting would is required to is atomic and a lock of a higher-level object would.

Because (object) through multithreading and a variety of access channels, generally it needs to maintain a mutual exclusion lock-otherwise the reference count is not required to be atomic, a higher level of the object lock enough.

And Linus doesn't think so:

The problem with reference counts is this you often need to take them *before* you take the lock that protects the object Data.

The problem with reference counting is that you often need to complete the object data before it is locked.

The thing is, for you have two different cases:

There are two types of problems:

-Object *reference* Objects Reference

-Object Data Objects

And they have completely different locking.

Their locking mechanism is completely different.

Object data locking is generally per-object. OK, unless don ' t have huge scalability issues, in which case your may have some external bigger lock (extreme Case:o NE single global Lock).

Object data protection is typically an object that has a lock, assuming you don't have a massive extensibility problem, or you need some big external lock (an extreme example, a global lock for an object).

But Object *referencing* is mostly about finding the object (and removing/freeing it). Is it in a hash chain? Is it in a tree? Linked list? When the reference count goes down to zero, it's not the object data, and you are need to protect (the object was not used by a Nything else, so there ' s No to protect!), it's the ways to find the object for you need to protect.

But an object reference is primarily about finding (removing or releasing) an object, whether it is on a hash chain, a tree, or a linked list. When the object reference count drops to zero, you are not protecting the object data, because the object is not used elsewhere, you want to protect the object's search operation.

And the lock for the lookup operation cannot being in the object, Because–by definition–you don ' t know what the object is ! You ' re trying the it up, after all.

And the lock on the query operation cannot be inside the object because, by definition, you don't know what the object is, you're trying to find it.

So generally your have a lock that protects the lookup operation some way, and the reference count needs to is atomic with respect to that lock.

So generally you have to lock the query operation, and the reference count is atomic to the lock: The query lock is not all the reference count, and the object reference count is not protected, and later explains why the object cannot be locked when the reference count changes.

And yes, that lock may is sufficient, and now you ' re back to non-atomic reference counts. But you usually don ' t have just one way-look things up:you the might have pointers from the other objects Protected by the object locking of the "other object", but there may be multiple such the "to" (Objects is Why you have a reference count in the the

This lock is, of course, fully valid and now assumes that the reference count is non atomic, but you often use more than just one way to query: You may have pointers to other objects (which are protected by the objects of other objects), but at the same time there are multiple objects pointing at it (which is why you need to quote the count for the first time.) )。

What happens? There is no longer a single lock for lookup. Imagine walking a graph of objects, where objects have pointers to each of the other. Each pointer implies a reference to an object, but as you walk the graph, and you have to release the lock from the source obj ECT, so your have to take a new reference to the object for your are now entering.

See what happens? There is more than one lock protection in the query. You can imagine walking through an object flowchart where an object has a pointer to another object, and each pointer implies an object reference, but when you walk through the flowchart, you have to release the lock on the source object, and you must add a reference when you enter the new object.

And in order to avoid deadlocks, with the "Can not" in "general case take" the lock of the new object first–you have to Relea Se the lock on the source object, because otherwise (in a complex graph), how do you avoid simple ABBA deadlock?

And in order to avoid deadlocks, you generally cannot lock new objects immediately-you must release the lock on the source object, or in a complex flowchart, how do you avoid ABBA deadlocks: Suppose two threads, one is A->b, the other b->; A, when the line Cheng to a lock, line Cheng to B lock, at this time neither one can release each other's lock)?

So atomic reference counts fix that. They work because when your move from Object A to object B, and can do this:

The atomic reference count fixes this, and when you go from Object A to object B, you do this:

(a) have a reference count to a, and you can lock a

Object A adds a reference count and locks it.

(b) Once object A is locked, the pointer from A to B are stable, and you know your have A reference to B (because of this PO Inter from A to B)

Once the object A is locked, a pointer to B is stable, so you know that you are referencing object B.

(c) But you cannot take the object lock for B (ABBA deadlock) while holding the lock on A

But you can't lock the B (ABBA deadlock) While object A is locked.

(d) Increment the atomic reference count on B

Object B increases the atomic reference count one time.

(e) Now and can drop the lock on a (' re "exiting" a ")

Now you can discard object A's Lock (Exit object a).

(f) Your reference count means that B cannot go away from under to despite A, so now you can lock B.

The atomic reference count of object B means that B will not be lost even if a lock is unlocked, and now you can lock the B.

What do you have? Atomic reference counts make this kind of situation possible. Yes, you want to avoid the overhead if in all possible (for example, maybe/have a strict ordering of objects, so/K Now we can walk from A to B, and never walk from B to a, so there are no ABBA deadlock, and can just lock B while stil L holding the lock on A).

See that? The atomic reference count makes this possible. Yes, you do everything you can to avoid the cost, for example, you may write the object in strict order, so that you can from a to B, never from B to a, so there is no ABBA deadlock, you will be locked during a lock to B.

But If you don ' t have some kind of forced ordering, and if your have multiple to reach an object (and ways again–why Reference counts in the ' the ' the ' if ' isn ' t true!) Then atomic reference counts really are the simple and sane.

But if you can't do this forced sequence, if you have multiple ways of contacting an object (again emphasizing that this is the first time to use the reference count), then the atomic reference count is a simple and sensible answer.

If you are atomic refcounts are unnecessary, that's a big flag this you don ' t actually understand the complexities of Lo Cking.

If you think that atomic reference counting is unnecessary, this is a big indication that you don't actually understand the complexity of locking mechanisms.

Trust me, concurrency is hard. There ' s A reason all the examples of ' look easy it's to parallelize things ' tend to-use simple arrays and don ' t ever Have allocations or freeing of the objects.

Believe me, concurrent design is difficult. All the reasons for "parallelization so Easy" tend to use simple array operations as examples, not even the allocation and release of objects.

People who-future-highly parallel are invariably completely unaware of just how hard concurrency really Is. They ' ve seen Linpack, They ' ve seen all those wonderful examples of sorting a array in parallel, They ' ve seen all these th Ings that have absolutely no actual real complexity–and often very real limited.

Those who think the future is highly parallel are invariably unaware of how difficult concurrent design is. They only saw Linpack, and they saw all the subtleties of array sequencing in parallel technology, and they only saw everything that was by no means truly complex-often very limited to true usefulness.

Of course, I did not intend to use the mouth of the great God to make the technology religious. In fact, Linus in another post to synthesize the evaluation of parallelism. )

Oh, I agree. My example is the simple case. The really complex cases are much worse.

Oh, I agree. My example is fairly simple, and the really complex use cases are worse.

I seriously don ' t believe that's the future is parallel. People who, can solve it with compilers or programming languages (or better programmers) are so far That is it ' s not even funny.

I seriously do not believe that the future is parallel. Some people think that you can solve problems with compilers, programming languages, or better programmers, who are currently delirious and unaware that this is not fun.

Parallelism works on simplified cases with fairly clear interfaces and models. You find parallelism in servers with independent queries, in HPC, in kernels, in databases. And even there, people work really hard to make it work in all and tend to expressly limit Le to it (eg databases does some things much better than others, so DB admins make sure this they lay out their the data in Orde R to cater to the limitations).

Parallel computing can work in simplified use cases and with clear interfaces and models. You find parallel on the server in a standalone query, in High-performance computing (High-performance Computing), in the kernel, in the database. Even so, it will take a lot of effort to make it work, and to explicitly limit their models to do more (for example, the database to do better, the database administrator to ensure that the data are properly arranged to meet the limitations).

Of course, other programming models can work. Neural networks are inherently very parallel. And you don ' t need smarter programmers to the program them either.

Of course, other programming models are useful, and neural networks (neural networking) are inherently very parallel, and you don't need smarter programmers to write code for them.

Resources

Real world Technologies:linus often goes to a forum on "watering" to discuss the future of machine architecture (see the name to know Linus technical preferences, and its previous to virtualization Technology (virtualization) of the slot)

Atomic nature of operations in multithreaded programs: Explaining why i++ is not an atomic operation

Concurrency is not parallelism:go the parent of the language Rob Pike slides explain the conceptual differences between concurrency and parallelism