On Tue, Aug 08, 2017 at 12:48:08AM +0800, Yubin Ruan wrote: > 2017-08-05 9:02 GMT+08:00 Yubin Ruan <ablacktshirt@xxxxxxxxx>: > > 2017-08-05 3:50 GMT+08:00 Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>: > >> On Fri, Aug 04, 2017 at 11:57:28PM +0800, Yubin Ruan wrote: > >>> 2017-08-04 22:52 GMT+08:00 Yubin Ruan <ablacktshirt@xxxxxxxxx>: > >>> > Hi, > >>> > I am sure the subject explain my intention. I got two processes trying > >>> > to modifying the same place. I want them to do it one after one, or, > >>> > if their operations interleave, I would like to let them know that the > >>> > content have been changed and polluted by the other so that the > >>> > content should be given up. That is, I would rather give up the data, > >>> > if polluted, than having a false one. > >>> > > >>> > I try to set a atomic ref counter, but it seems impossible to do that > >>> > without a lock to synchronize. > >>> > > >>> > Note that I don't want a strict synchronization: the situation is a > >>> > lot better. The data can be given up if that place has been polluted. > >>> > >>> Let's explain some of my reasoning: if process A use some flag to > >>> indicate that it has entered the critical region, then if it crash > >>> before it can reset the flag, all following processes cannot enter > >>> that region. But if process A cannot use flag for indication, how to > >>> other people know (how to synchronization)? > >> > >> The simplest approach is to guard the data with a lock. > > > > Indeed. But if a process get killed then it will have no chance to release > > the lock... > > > > By the way, do you know whether there are any chances that a thread get > > killed by another thread when doing some "small" things? I mean something > > like this: > > > > lock(); > > some_mem_copying(); > > unlock(); > > > > Are there any chance that a thread get killed by another thread before it > > can "unlock()", without the entire process going down? Indeed, that is possible. The pthread_kill() system call if nothing else. > pthread_mutexattr_setrobust(..) will help in this situation, although it is > quite painful that nobody is maintaining the NPTL docs currently and you have > to dive into the source code if you want to make sure the semantic is exactly > what you want. True on all counts. But what exactly are you trying to achieve? Note that killing a thread not holding any lock can be a problem, for example, suppose the thread that is to place a new element gets killed just before doing so. How do you intend to handle that situation? > Yubin > > >> But if you don't want to do that, another approach is to restrict the > >> data to one machine word minus one bit, with zero saying that the location > >> is (as you say) unpolluted. Then you can use a compare-and-swap loop > >> to update the location only if it is unpolluted. > >> > >> But maybe you need more data. If so, you can have the data separately > >> (perhaps dynamically allocated, perhaps not, your choice), and then use > >> the compare-and-swap method above where NULL says unpolluted. > > > > Good suggestion... although I think it would be pretty painful. Well, if you are going for full-up fault tolerance, you are in for a world of pain regardless. Fault tolerance is non-trivial any way you look at it. Therefore, my advice is to very carefully work out what your users really need, and implement exactly that. Doing "just a bit more" in this area usually means incurring a huge amount more pain, often incurred later in the project. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe perfbook" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
