6d5 Subj : Re: How to manage time-slicing in Pthreads programs? To : comp.programming.threads From : David Schwartz Date : Sun Feb 20 2005 02:32 am "D'artagnan" wrote in message news:1108878020.448490.61910@g14g2000cwa.googlegroups.com... > I guess this means thread B doesn't have a direct way to put thread A > to sleep. No. > Because the distribution of those special objects (those inducing > conflicts) is random and nonderministic in the input data. It's hard to > know before run time which objects should be locked. Locking (even > non-blocking) each item generates too much unwanted overhead. You benchmarked this? Premature optimization is not good. >> No thread ever needs to go to sleep. Just have each thread take >> the >> first untaken item. > Without locking up an object, you cannot be sure if it has been > accessed by the other thread or not. Use a non-blocking lock, like pthread_mutex_trylock. >> There are ways to do this, but they all involve thread B telling >> thread >> A to go to sleep, > How? Are these ways involving signals? I kind of remember signals in > Linux threads are somewhat goofy. Am I wrong? No, not signals. Just setting a variable. > Basically, what I'm headed for here is that I want user-level atomic > operations. Locks in Pthreads synchronize accesses to shared locations, > but multiple threads can still execute the same operation at the same > time. An atomic operation is one that once started by a thread it runs > to its completion without being swapped out and back. You don't want atomic operations anyway, you just want to prevent concurrent conflicting operations. DS . 0