| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | Using RCU to Protect Read-Mostly Arrays | 
 | 2 |  | 
 | 3 |  | 
 | 4 | Although RCU is more commonly used to protect linked lists, it can | 
 | 5 | also be used to protect arrays.  Three situations are as follows: | 
 | 6 |  | 
 | 7 | 1.  Hash Tables | 
 | 8 |  | 
 | 9 | 2.  Static Arrays | 
 | 10 |  | 
 | 11 | 3.  Resizeable Arrays | 
 | 12 |  | 
 | 13 | Each of these situations are discussed below. | 
 | 14 |  | 
 | 15 |  | 
 | 16 | Situation 1: Hash Tables | 
 | 17 |  | 
 | 18 | Hash tables are often implemented as an array, where each array entry | 
 | 19 | has a linked-list hash chain.  Each hash chain can be protected by RCU | 
 | 20 | as described in the listRCU.txt document.  This approach also applies | 
 | 21 | to other array-of-list situations, such as radix trees. | 
 | 22 |  | 
 | 23 |  | 
 | 24 | Situation 2: Static Arrays | 
 | 25 |  | 
 | 26 | Static arrays, where the data (rather than a pointer to the data) is | 
 | 27 | located in each array element, and where the array is never resized, | 
 | 28 | have not been used with RCU.  Rik van Riel recommends using seqlock in | 
 | 29 | this situation, which would also have minimal read-side overhead as long | 
 | 30 | as updates are rare. | 
 | 31 |  | 
 | 32 | Quick Quiz:  Why is it so important that updates be rare when | 
 | 33 | 	     using seqlock? | 
 | 34 |  | 
 | 35 |  | 
 | 36 | Situation 3: Resizeable Arrays | 
 | 37 |  | 
 | 38 | Use of RCU for resizeable arrays is demonstrated by the grow_ary() | 
 | 39 | function used by the System V IPC code.  The array is used to map from | 
 | 40 | semaphore, message-queue, and shared-memory IDs to the data structure | 
 | 41 | that represents the corresponding IPC construct.  The grow_ary() | 
 | 42 | function does not acquire any locks; instead its caller must hold the | 
 | 43 | ids->sem semaphore. | 
 | 44 |  | 
 | 45 | The grow_ary() function, shown below, does some limit checks, allocates a | 
 | 46 | new ipc_id_ary, copies the old to the new portion of the new, initializes | 
 | 47 | the remainder of the new, updates the ids->entries pointer to point to | 
 | 48 | the new array, and invokes ipc_rcu_putref() to free up the old array. | 
 | 49 | Note that rcu_assign_pointer() is used to update the ids->entries pointer, | 
 | 50 | which includes any memory barriers required on whatever architecture | 
 | 51 | you are running on. | 
 | 52 |  | 
 | 53 | 	static int grow_ary(struct ipc_ids* ids, int newsize) | 
 | 54 | 	{ | 
 | 55 | 		struct ipc_id_ary* new; | 
 | 56 | 		struct ipc_id_ary* old; | 
 | 57 | 		int i; | 
 | 58 | 		int size = ids->entries->size; | 
 | 59 |  | 
 | 60 | 		if(newsize > IPCMNI) | 
 | 61 | 			newsize = IPCMNI; | 
 | 62 | 		if(newsize <= size) | 
 | 63 | 			return newsize; | 
 | 64 |  | 
 | 65 | 		new = ipc_rcu_alloc(sizeof(struct kern_ipc_perm *)*newsize + | 
 | 66 | 				    sizeof(struct ipc_id_ary)); | 
 | 67 | 		if(new == NULL) | 
 | 68 | 			return size; | 
 | 69 | 		new->size = newsize; | 
 | 70 | 		memcpy(new->p, ids->entries->p, | 
 | 71 | 		       sizeof(struct kern_ipc_perm *)*size + | 
 | 72 | 		       sizeof(struct ipc_id_ary)); | 
 | 73 | 		for(i=size;i<newsize;i++) { | 
 | 74 | 			new->p[i] = NULL; | 
 | 75 | 		} | 
 | 76 | 		old = ids->entries; | 
 | 77 |  | 
 | 78 | 		/* | 
 | 79 | 		 * Use rcu_assign_pointer() to make sure the memcpyed | 
 | 80 | 		 * contents of the new array are visible before the new | 
 | 81 | 		 * array becomes visible. | 
 | 82 | 		 */ | 
 | 83 | 		rcu_assign_pointer(ids->entries, new); | 
 | 84 |  | 
 | 85 | 		ipc_rcu_putref(old); | 
 | 86 | 		return newsize; | 
 | 87 | 	} | 
 | 88 |  | 
 | 89 | The ipc_rcu_putref() function decrements the array's reference count | 
 | 90 | and then, if the reference count has dropped to zero, uses call_rcu() | 
 | 91 | to free the array after a grace period has elapsed. | 
 | 92 |  | 
 | 93 | The array is traversed by the ipc_lock() function.  This function | 
 | 94 | indexes into the array under the protection of rcu_read_lock(), | 
 | 95 | using rcu_dereference() to pick up the pointer to the array so | 
 | 96 | that it may later safely be dereferenced -- memory barriers are | 
 | 97 | required on the Alpha CPU.  Since the size of the array is stored | 
 | 98 | with the array itself, there can be no array-size mismatches, so | 
 | 99 | a simple check suffices.  The pointer to the structure corresponding | 
 | 100 | to the desired IPC object is placed in "out", with NULL indicating | 
 | 101 | a non-existent entry.  After acquiring "out->lock", the "out->deleted" | 
 | 102 | flag indicates whether the IPC object is in the process of being | 
 | 103 | deleted, and, if not, the pointer is returned. | 
 | 104 |  | 
 | 105 | 	struct kern_ipc_perm* ipc_lock(struct ipc_ids* ids, int id) | 
 | 106 | 	{ | 
 | 107 | 		struct kern_ipc_perm* out; | 
 | 108 | 		int lid = id % SEQ_MULTIPLIER; | 
 | 109 | 		struct ipc_id_ary* entries; | 
 | 110 |  | 
 | 111 | 		rcu_read_lock(); | 
 | 112 | 		entries = rcu_dereference(ids->entries); | 
 | 113 | 		if(lid >= entries->size) { | 
 | 114 | 			rcu_read_unlock(); | 
 | 115 | 			return NULL; | 
 | 116 | 		} | 
 | 117 | 		out = entries->p[lid]; | 
 | 118 | 		if(out == NULL) { | 
 | 119 | 			rcu_read_unlock(); | 
 | 120 | 			return NULL; | 
 | 121 | 		} | 
 | 122 | 		spin_lock(&out->lock); | 
 | 123 |  | 
 | 124 | 		/* ipc_rmid() may have already freed the ID while ipc_lock | 
 | 125 | 		 * was spinning: here verify that the structure is still valid | 
 | 126 | 		 */ | 
 | 127 | 		if (out->deleted) { | 
 | 128 | 			spin_unlock(&out->lock); | 
 | 129 | 			rcu_read_unlock(); | 
 | 130 | 			return NULL; | 
 | 131 | 		} | 
 | 132 | 		return out; | 
 | 133 | 	} | 
 | 134 |  | 
 | 135 |  | 
 | 136 | Answer to Quick Quiz: | 
 | 137 |  | 
 | 138 | 	The reason that it is important that updates be rare when | 
 | 139 | 	using seqlock is that frequent updates can livelock readers. | 
 | 140 | 	One way to avoid this problem is to assign a seqlock for | 
 | 141 | 	each array entry rather than to the entire array. |