pthread_lock

pthread_lock

[ishare]

 when pthread_unlock(mutex) is called , do other threads waiting for mutex be waked up immediately?
 or be waked up at the next schedule?

  

pthread_lock

[Mandeep Sandhu]

On Tue, Mar 5, 2013 at 10:14 AM, ishare <june.tune.sea@gmail.com> wrote:
>
>
>  when pthread_unlock(mutex) is called , do other threads waiting for mutex be waked up immediately?
>  or be waked up at the next schedule?

next schedule. I think the waiting threads (processes) will moved from
the wait queue to the run queue from where they will be scheduled to
run.

HTH,
-mandeep

>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

pthread_lock

[Valdis.Kletnieks at vt.edu]

On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:

> next schedule. I think the waiting threads (processes) will moved from
> the wait queue to the run queue from where they will be scheduled to
> run.

For bonus points, read source code and/or comments and figure out what
Linux does to prevent the 'thundering herd' problem (consider 100 threads
all waiting on the same mutex - if you blindly wake all 100 up, you'll schedule
them all, the first will find the mutex available and then re-take it, and
then the next 99 will get run only to find it contended and go back to
sleep.  So figure out what Linux does in that case. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130305/9bdeb5af/attachment.bin 

pthread_lock

[Mandeep Sandhu]

On Tue, Mar 5, 2013 at 11:32 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
>
>> next schedule. I think the waiting threads (processes) will moved from
>> the wait queue to the run queue from where they will be scheduled to
>> run.
>
> For bonus points, read source code and/or comments and figure out what
> Linux does to prevent the 'thundering herd' problem (consider 100 threads
> all waiting on the same mutex - if you blindly wake all 100 up, you'll schedule
> them all, the first will find the mutex available and then re-take it, and
> then the next 99 will get run only to find it contended and go back to
> sleep.  So figure out what Linux does in that case. :)

Googling around, I found the 'thundering herd' being mentioned in
relation to threads waiting on sockets using the accept() sys call.
Are wait's on mutex's also plagued by the same issue? I guess it is,
though what sys call would be used in this case?

Thanks,
-mandeep

pthread_lock

[ishare]

On Tue, Mar 05, 2013 at 01:39:54PM +0530, Mandeep Sandhu wrote:
> On Tue, Mar 5, 2013 at 11:32 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> > On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
> >
> >> next schedule. I think the waiting threads (processes) will moved from
> >> the wait queue to the run queue from where they will be scheduled to
> >> run.
> >
> > For bonus points, read source code and/or comments and figure out what
> > Linux does to prevent the 'thundering herd' problem (consider 100 threads
> > all waiting on the same mutex - if you blindly wake all 100 up, you'll schedule
> > them all, the first will find the mutex available and then re-take it, and
> > then the next 99 will get run only to find it contended and go back to
> > sleep.  So figure out what Linux does in that case. :)
> 
> Googling around, I found the 'thundering herd' being mentioned in
> relation to threads waiting on sockets using the accept() sys call.
> Are wait's on mutex's also plagued by the same issue? I guess it is,
> though what sys call would be used in this case?
  
 the threads waiting on sockets will be waked up by net event.
 similarly,the waiters  on mutex's can be wake up by signal.I guess it is pthread_cont_signal 
  

> 
> Thanks,
> -mandeep

pthread_lock

[Prabhu nath]

I guess we should not mix mutex and condition variable. Both have their own
respective semantics.
*mutex* is used to serialize access to a shared resource among competing
threads.
*condition variable* is used to notify a* state change* of a resource to
the interested thread.

In case of condition variable there is provision to explicitly notify a
single thread(pthread_cond_signal) or all the threads waiting on a
condition (or a state change) (pthread_cond_broadcast)

Question was on pthread_mutex_unlock() that whether this function
invocation will trigger the movement of all the threads in the wait queue
to the ready queue.
If all the threads are of equal priority, then the first thread waiting for
the lock will be put to READY queue.
If there are variable priority threads waiting for the lock, then the
thread with highest priority would be woken up

Regards,
Prabhunath G
Linux Trainer
Bangalore


On Tue, Mar 5, 2013 at 3:35 PM, ishare <june.tune.sea@gmail.com> wrote:

> On Tue, Mar 05, 2013 at 01:39:54PM +0530, Mandeep Sandhu wrote:
> > On Tue, Mar 5, 2013 at 11:32 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> > > On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
> > >
> > >> next schedule. I think the waiting threads (processes) will moved from
> > >> the wait queue to the run queue from where they will be scheduled to
> > >> run.
> > >
> > > For bonus points, read source code and/or comments and figure out what
> > > Linux does to prevent the 'thundering herd' problem (consider 100
> threads
> > > all waiting on the same mutex - if you blindly wake all 100 up, you'll
> schedule
> > > them all, the first will find the mutex available and then re-take it,
> and
> > > then the next 99 will get run only to find it contended and go back to
> > > sleep.  So figure out what Linux does in that case. :)
> >
> > Googling around, I found the 'thundering herd' being mentioned in
> > relation to threads waiting on sockets using the accept() sys call.
> > Are wait's on mutex's also plagued by the same issue? I guess it is,
> > though what sys call would be used in this case?
>
>  the threads waiting on sockets will be waked up by net event.
>  similarly,the waiters  on mutex's can be wake up by signal.I guess it is
> pthread_cont_signal
>
>
> >
> > Thanks,
> > -mandeep
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130312/c3f76b72/attachment.html 

pthread_lock

[ishare]

On Tue, Mar 12, 2013 at 06:18:02PM +0530, Prabhu nath wrote:
> I guess we should not mix mutex and condition variable. Both have their own
> respective semantics.
> *mutex* is used to serialize access to a shared resource among competing
> threads.
> *condition variable* is used to notify a* state change* of a resource to
> the interested thread.
> 
> In case of condition variable there is provision to explicitly notify a
> single thread(pthread_cond_signal) or all the threads waiting on a
> condition (or a state change) (pthread_cond_broadcast)
> 
> Question was on pthread_mutex_unlock() that whether this function
> invocation will trigger the movement of all the threads in the wait queue
> to the ready queue.
  
  After pthread_mutex_unlock() is called , the mutex is release , then ,which stuff 
  will reshcedule the threads in the waitqueue ?

  If do pthread_cond_signal() after each pthread_mutex_unlock() ,does it raise up the performence  ? 
 
  thanks!







> If all the threads are of equal priority, then the first thread waiting for
> the lock will be put to READY queue.
> If there are variable priority threads waiting for the lock, then the
> thread with highest priority would be woken up


  

pthread_lock

[Prabhu nath]

On Wed, Mar 13, 2013 at 9:40 AM, ishare <june.tune.sea@gmail.com> wrote:

> On Tue, Mar 12, 2013 at 06:18:02PM +0530, Prabhu nath wrote:
> > I guess we should not mix mutex and condition variable. Both have their
> own
> > respective semantics.
> > *mutex* is used to serialize access to a shared resource among competing
> > threads.
> > *condition variable* is used to notify a* state change* of a resource to
> > the interested thread.
> >
> > In case of condition variable there is provision to explicitly notify a
> > single thread(pthread_cond_signal) or all the threads waiting on a
> > condition (or a state change) (pthread_cond_broadcast)
> >
> > Question was on pthread_mutex_unlock() that whether this function
> > invocation will trigger the movement of all the threads in the wait queue
> > to the ready queue.
>
>   After pthread_mutex_unlock() is called , the mutex is release , then
> ,which stuff
>   will reshcedule the threads in the waitqueue ?
>
>   If do pthread_cond_signal() after each pthread_mutex_unlock() ,does it
> raise up the performence  ?
>
>   thanks!
>
I think you are missing something in your understanding. Please refer
"Programming with POSIX threads" - David R. Butenhof



>
>
>
>
>
> > If all the threads are of equal priority, then the first thread waiting
> for
> > the lock will be put to READY queue.
> > If there are variable priority threads waiting for the lock, then the
> > thread with highest priority would be woken up
>
>
>
>


-- 
Regards,
Prabhunath G
Linux Trainer
Bangalore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130313/05d6bda1/attachment.html