On Sat, Jun 09, 2007 at 09:36:22PM +0300, Muli Ben-Yehuda wrote: > On Sat, Jun 09, 2007 at 09:31:41PM +0300, Shachar Shemesh wrote: > > Muli Ben-Yehuda wrote: > > > > > > What happens if you you set thread scheduling to SCHED_FIFO (using > > > pthread_attr_setschedpolicy(SCHED_FIFO), assuming > > > _POSIX_THREAD_PRIORITY_SCHEDULING is defined on your system)? > > > > > When I manage to decypher what the !#@)!(@# the parameters in the > > man page mean, I'll try to let you know. The pthreads man page is > > one of the worst. > > I usually skim the man pages and then head for the > source... basically, setting the scheduling policy for the threads to > SCHED_RR (see my other email) *should* make each thread run for some > amount of time and then give the rest of the threads an opportunity to > run. This could lead to observed fairness on the mutex.
.. haveing said that, the discussion at http://groups.google.com/group/comp.programming.threads/browse_frm/thread/d3703aae792a7d18/7af5937891e059eb?hl=en&; should prove illuminating. The bottom line is that there's no inherent guarantee of fairness for such "tight unlock/lock loops", but you may be able to coax some versions of glibc into giving you a semblance of fairness by creating the mutex with type 'PTHREAD_MUTEX_ERRORCHECK_NP', or - and this is the preferred solution - implement fairness yourself if you need it. Cheers, Muli ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
