.. | .. |
---|
34 | 34 | 8. The array can iterated over. The objects will not necessarily come out in |
---|
35 | 35 | key order. |
---|
36 | 36 | |
---|
37 | | -9. The array can be iterated over whilst it is being modified, provided the |
---|
| 37 | +9. The array can be iterated over while it is being modified, provided the |
---|
38 | 38 | RCU readlock is being held by the iterator. Note, however, under these |
---|
39 | 39 | circumstances, some objects may be seen more than once. If this is a |
---|
40 | 40 | problem, the iterator should lock against modification. Objects will not |
---|
.. | .. |
---|
42 | 42 | |
---|
43 | 43 | 10. Objects in the array can be looked up by means of their index key. |
---|
44 | 44 | |
---|
45 | | -11. Objects can be looked up whilst the array is being modified, provided the |
---|
| 45 | +11. Objects can be looked up while the array is being modified, provided the |
---|
46 | 46 | RCU readlock is being held by the thread doing the look up. |
---|
47 | 47 | |
---|
48 | 48 | The implementation uses a tree of 16-pointer nodes internally that are indexed |
---|
.. | .. |
---|
273 | 273 | enough memory. |
---|
274 | 274 | |
---|
275 | 275 | It is possible for other threads to iterate over or search the array under |
---|
276 | | -the RCU read lock whilst this function is in progress. The caller should |
---|
| 276 | +the RCU read lock while this function is in progress. The caller should |
---|
277 | 277 | lock exclusively against other modifiers of the array. |
---|
278 | 278 | |
---|
279 | 279 | |
---|