On Fri, Oct 01, 2004 at 05:01:06PM -0400, lml@xxxxxxxxxxxxxxxx wrote: > Hi, Greg, > > On Fri, Oct 01, 2004 at 01:14:56PM -0700, Greg KH wrote: > > On Fri, Oct 01, 2004 at 03:50:56PM -0400, lml@xxxxxxxxxxxxxxxx wrote: > > > Hi, > > > > > > I am not sure how the reference counter can protect the data by just > > > checking the number of usage. For example, one thread gets the object > > > and increases the counter, while another can get the same object at > > > the same time. If there is no locking, how can the reference counter > > > solve the race contention. > > > > > > Or may be I missed some important part. > > > > You did. Your reference count needs to be an atomic value. Just use a > > struct kref, it handles all of the logic for you. > > Yes, I know the reference counter is usually atomic_t, but two threads > can "get" the object and this "get" only increases the atomic value. No, an atomic value will always work properly (it will be incremented twice.) Remember that almost all locks are created using atomic values, because of this property. > After that, they canread/write the object at the same time, right? It > sounds like only the reference counter is atomic, while the content of > the object is not protected. Please correct me if I am wrong. Yes, they could both use the object at the same time. But if you need to protect from that, you need a lock, not only a reference count. > I am still using 2.4 kernel so there is no struct kref, but the > principle, which I am not clear, should be the same. Feel free to backport kref to 2.4 if it would help you out. Hope this helps, greg k-h -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
