72e
Subj : Re: How to manage time-slicing in Pthreads programs?
To   : comp.programming.threads
From : David Schwartz
Date : Sat Feb 19 2005 06:42 pm


"D'artagnan" <musketeers@gmail.com> wrote in message 
news:1108864881.967818.199940@g14g2000cwa.googlegroups.com...

> OK, maybe I didn't explain the situation clearly in my first post. In
> my example, I don't want thread A to put itself to sleep, I want thread
> B to put it to sleep and wake it up later.

    That doesn't make sense.

> Consider the following
> senario: thread A and thread B are processing a huge collection of
> items, one-by-one. The workload is split up between the two threads
> such that 99% chance there aren't conflicting accesses between the two
> threads.  For the 1% chance of conflicting accesses we need some
> protection. The problem is that thread A never knows which items will
> cause conflicting accesses, only thread B has this knowledge.

    Why not just lock the conflicting objects with a non-blocking lock? If a 
thread can't get the lock on an object, it just goes on to the next one.

> Therefore, pthread_cond_wait() doesn't apply here because (1) thead A
> doesn't know when to wait; and (2) if thread B calls it and goes to
> sleep, there is nobody to wake it up.

    No thread ever needs to go to sleep. Just have each thread take the 
first untaken item.

> The desired scheme would be: When thread B becomes aware of a potential
> conflicting access, it puts thread A into sleep. Thread B finishes the
> access, then wakes thread A up. Are there any ways to do this? Thanks.

    There are ways to do this, but they all involve thread B telling thread 
A to go to sleep, and thread A receiving the request and then putting itself 
to sleep. Smarter to lock the data in most cases.

    DS

.

0