Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #630 > unrolled thread

can pthread_mutex_trylock() give up the timeslice?

Back to article view | Back to comp.programming.threads

Contents

  can pthread_mutex_trylock() give up the timeslice? Brendon <brendon.j.costa@gmail.com> - 2011-10-13 16:05 -0700
    Re: can pthread_mutex_trylock() give up the timeslice? Alexander Terekhov <terekhov@web.de> - 2011-10-14 11:50 +0200
    Re: can pthread_mutex_trylock() give up the timeslice? Joshua Maurice <joshuamaurice@gmail.com> - 2011-10-14 13:43 -0700
      Re: can pthread_mutex_trylock() give up the timeslice? Brendon <brendon.j.costa@gmail.com> - 2011-10-14 16:56 -0700
        Re: can pthread_mutex_trylock() give up the timeslice? Alexander Terekhov <terekhov@web.de> - 2011-10-15 13:53 +0200
    Re: can pthread_mutex_trylock() give up the timeslice? David Schwartz <davids@webmaster.com> - 2011-10-15 21:41 -0700

#630 — can pthread_mutex_trylock() give up the timeslice?

**context**
I am working on a bit of code, where a thread has a queue of work to
do and as it is starting to run out of work it asks for more work.
This process of asking for more work requires a lock on a common task
queue. However because the thread asks for more before running out if
the thread is unable to obtain the lock it will continue doing more
work and ask again in a little while. This right now uses a
pthread_mutex_trylock()

If the thread runs out of work completely it blocks waiting for the
lock as there is nothing more it can do and that just uses
pthread_mutex_lock().

**question**
My question is (i cant seem to find the definitive answer anywhere),
is it POSSIBLE that pthread_mutex_trylock() can give up the current
timeslice?

I assume the answer is that trylock will NOT give up the timeslice but
I cant find any explicit verification of that and someone said to me
in passing that it could. The man page says pthread_mutex_trylock()
will return immediatly which to me means it will not give up the
timeslice. Any comments?

Thanks,
Brendon.

[toc] | [next] | [standalone]

#631

Brendon wrote:
> 
> **context**
> I am working on a bit of code, where a thread has a queue of work to
> do and as it is starting to run out of work it asks for more work.
> This process of asking for more work requires a lock on a common task
> queue. However because the thread asks for more before running out if
> the thread is unable to obtain the lock it will continue doing more
> work and ask again in a little while. This right now uses a
> pthread_mutex_trylock()
> 
> If the thread runs out of work completely it blocks waiting for the
> lock as there is nothing more it can do and that just uses
> pthread_mutex_lock().
> 
> **question**
> My question is (i cant seem to find the definitive answer anywhere),
> is it POSSIBLE that pthread_mutex_trylock() can give up the current
> timeslice?

If you are not running in a hard realtime environment, a thread can give
up the current timeslice at any time.

regards,
alexander.

[toc] | [prev] | [next] | [standalone]

#632

On Oct 13, 4:05 pm, Brendon <brendon.j.co...@gmail.com> wrote:
> **context**
> I am working on a bit of code, where a thread has a queue of work to
> do and as it is starting to run out of work it asks for more work.
> This process of asking for more work requires a lock on a common task
> queue. However because the thread asks for more before running out if
> the thread is unable to obtain the lock it will continue doing more
> work and ask again in a little while. This right now uses a
> pthread_mutex_trylock()
>
> If the thread runs out of work completely it blocks waiting for the
> lock as there is nothing more it can do and that just uses
> pthread_mutex_lock().
>
> **question**
> My question is (i cant seem to find the definitive answer anywhere),
> is it POSSIBLE that pthread_mutex_trylock() can give up the current
> timeslice?
>
> I assume the answer is that trylock will NOT give up the timeslice but
> I cant find any explicit verification of that and someone said to me
> in passing that it could. The man page says pthread_mutex_trylock()
> will return immediatly which to me means it will not give up the
> timeslice. Any comments?

AFAIK, the idea is that trylock will not context swap to another
thread. I might consider an implementation broken which was
implemented to context swap out. Still, you might get swapped out at
any time from exhausting your timeslice, and you might get swapped out
at any time because nothing explicitly prohibits it (unless you're
very careful with thread priorities and realtime stuff which is beyond
my scope of knowledge).

I ask why this matters so much. What are your requirements? Do you /
really/ need that guarantee?

[toc] | [prev] | [next] | [standalone]

#634

> I ask why this matters so much. What are your requirements? Do you /
> really/ need that guarantee?

Thanks for the response.

I dont *require* the guarantee but knowing the basic characteristics
helps me tune the performance of this code (The current implementation
is using a normal lock which is often contended and the result is non-
optimal performance). For example, if pthread_mutex_trylock() did
occasionally give up the timeslice as does the normal
pthread_mutex_lock(), then I would be better keeping with the normal
lock.

I understand that the timeslice can be exhausted and another thread
scheduled as in normal operation without a proper realtime
environment, but on the whole Linux seems to schedule things fairly
well for this application.

The point is simply that the performance is better for this code if
pthread_mutex_trylock() does not to give up the timeslice prematurely
and in this particular application (highly scalable audio processing
server, which we can't enforce a realtime environment on our
customers) this performance is quite important.

If for example the trylock may prematurely give up the timeslice (I
agree that others are correct in that if there is an implementation
that does this then it is probably a bug and I dont really care as
long as it is not common), then I might be better looking into a non-
blocking data structure for the queue.

My plan now will be just to go along and do the work using a try-lock
(not a huge change) if it shows some issues then look at another
solution. I just wanted to ask and see if anyone here has heard of
pthread_mutex_trylock() prematurely giving up a timeslice and so far
it sounds like the answer is no (Which makes me happy :-) ).

Thanks,
Brendon.

[toc] | [prev] | [next] | [standalone]

#636

Brendon wrote:
[...]
> My plan now will be just to go along and do the work using a try-lock
> (not a huge change) if it shows some issues then look at another
> solution. I just wanted to ask and see if anyone here has heard of
> pthread_mutex_trylock() prematurely giving up a timeslice and so far

Realtime aside, implementations of pthread_mutex_trylock() are allowed
to give up a time slice.

If you really think that that is a problem for your code then use C/C++
atomics to implement your own mutex with trylock() not giving up a
timeslice:

http://lists.boost.org/Archives/boost/2004/05/65435.php
(auto_reset_event is a binary semaphore in posix speak)

regards,
alexander.

[toc] | [prev] | [next] | [standalone]

#637

On Oct 13, 4:05 pm, Brendon <brendon.j.co...@gmail.com> wrote:

> **question**
> My question is (i cant seem to find the definitive answer anywhere),
> is it POSSIBLE that pthread_mutex_trylock() can give up the current
> timeslice?

Yes.

> I assume the answer is that trylock will NOT give up the timeslice but
> I cant find any explicit verification of that and someone said to me
> in passing that it could. The man page says pthread_mutex_trylock()
> will return immediatly which to me means it will not give up the
> timeslice. Any comments?

Assuming the implementers know what they're doing, they wouldn't make
it give up the timeslice unless that conveyed some benefit. Use the
function for its intended purpose, which it sounds like you are doing,
and don't worry about these kinds of details -- they're not your
problem.

DS

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web