Re: Is pthread_cond_signal(3) man page correct?

2011-03-17 Thread Yuri 

On 03/16/2011 19:20, Garrett Cooper wrote:

So yes, EINTR not being allowed is by design and this backs up what
davidxu@ is stating above. Our manpage just doesn't explicitly call
this requirement out, unlike a Linux manpage I dug up and the
OpenGroup manpage.
   


I apologize for keeping asking, but David Xu mentioned before that 
signal can also be delivered at the same time and pthread_cond_signal 
will exit. Normally its EINTR (like for open(2)). But now you are saying 
that EINTR isn't allowed for pthread_cond_signal. So does this mean that 
signal can't be delivered during pthread_cond_signal, or it will just 
return 0? In the latter case, how can I distinguish signal delivery and 
successful return?


Yuri
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-03-16 Thread Yuri 

On 02/27/2011 18:00, David Xu wrote:

I think in normal case, pthread_cond_signal will wake up one thread,
but other events for example, UNIX signal and fork() may interrupt
a thread sleeping in kernel, and cause pthread_cond_wait to return
to userland, this is called spurious wakeup, and other events, I
can not think of yet, but I believe they exist.
   


Does this mean that pthread_cond_signal can also return EINTR? This 
isn't in pthread_cond_signal(3) either.


Is this the case that all system calls should be assumed to be able to 
return EINTR or only those that have EINTR in their man pages?


Yuri
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-03-16 Thread David Xu 
On 2011/03/16 23:23, Yuri wrote:
 On 02/27/2011 18:00, David Xu wrote:
 I think in normal case, pthread_cond_signal will wake up one thread,
 but other events for example, UNIX signal and fork() may interrupt
 a thread sleeping in kernel, and cause pthread_cond_wait to return
 to userland, this is called spurious wakeup, and other events, I
 can not think of yet, but I believe they exist.

 
 Does this mean that pthread_cond_signal can also return EINTR? This
 isn't in pthread_cond_signal(3) either.
 

No, it will return zero, returning EINTR is not allowed.

 Is this the case that all system calls should be assumed to be able to
 return EINTR or only those that have EINTR in their man pages?
 
 Yuri
 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-03-16 Thread Garrett Cooper 
On Wed, Mar 16, 2011 at 6:54 PM, David Xu davi...@freebsd.org wrote:
 On 2011/03/16 23:23, Yuri wrote:
 On 02/27/2011 18:00, David Xu wrote:
 I think in normal case, pthread_cond_signal will wake up one thread,
 but other events for example, UNIX signal and fork() may interrupt
 a thread sleeping in kernel, and cause pthread_cond_wait to return
 to userland, this is called spurious wakeup, and other events, I
 can not think of yet, but I believe they exist.


 Does this mean that pthread_cond_signal can also return EINTR? This
 isn't in pthread_cond_signal(3) either.


 No, it will return zero, returning EINTR is not allowed.

Adding some more context by adding the appropriate POSIX spec material...

RETURN VALUE

If successful, the pthread_cond_broadcast() and
pthread_cond_signal() functions shall return zero; otherwise, an error
number shall be returned to indicate the error.

ERRORS

The pthread_cond_broadcast() and pthread_cond_signal() function may fail if:

[EINVAL]
The value cond does not refer to an initialized condition variable.

These functions shall not return an error code of [EINTR].

So yes, EINTR not being allowed is by design and this backs up what
davidxu@ is stating above. Our manpage just doesn't explicitly call
this requirement out, unlike a Linux manpage I dug up and the
OpenGroup manpage.

 Is this the case that all system calls should be assumed to be able to
 return EINTR or only those that have EINTR in their man pages?

Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-02-28 Thread Yuri 

On 28.02.11 2:41, Pieter de Goeje wrote:

pthread_cond_signal() can indeed wake up more than one thread. That's why you
should always wrap pthread_cond_wait() in a loop. For example a blocking
queue could be implemented like this (pseudo code):


Thank you. Now its clear that POSIX allows multiple wake ups.

But my question is: why would the standard define it this way? Why would 
it allow essentially arbitrary number of waiting threads to be woken up 
by one event? I can't think of any practical app that would need some 
threads to be woken up. It would be natural to expect it to wake 
exactly one thread. So the users won't need to have any special cycles 
like you suggested in your previous post.


What is the underlying reason for POSIX to define it this way and for 
OSes to implement it this way?


Yuri
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-02-28 Thread Pieter de Goeje 
On Monday 28 February 2011 16:08:32 Yuri wrote:
 On 28.02.11 2:41, Pieter de Goeje wrote:
  pthread_cond_signal() can indeed wake up more than one thread. That's why
  you should always wrap pthread_cond_wait() in a loop. For example a
  blocking
 
  queue could be implemented like this (pseudo code):
 Thank you. Now its clear that POSIX allows multiple wake ups.
 
 But my question is: why would the standard define it this way? Why would
 it allow essentially arbitrary number of waiting threads to be woken up
 by one event? I can't think of any practical app that would need some
 threads to be woken up. It would be natural to expect it to wake
 exactly one thread. So the users won't need to have any special cycles
 like you suggested in your previous post.
 
 What is the underlying reason for POSIX to define it this way and for
 OSes to implement it this way?

Well you need the extra cycles anyway because pthread_cond_wait() can wakeup 
for no apparent reason. As David Xu explained, in FreeBSD this can for 
instance happen because a signal is delivered to the process or the process 
called fork().

For pthread library implementors its probably easier (faster) to guarantee 
that at least one thread will be woken by pthread_cond_signal() instead of 
exactly one. Because the application needs to check the condition's predicate 
anyway it's logical to allow for a more relaxed specification. In that sense, 
pthread_cond_signal() is only here because it is a lot faster than calling 
pthread_cond_broadcast() all the time (because of the thundering herd 
problem).

- Pieter
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-02-27 Thread Yuri 

Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion.

Also I want to add that I came to this question while observing behavior 
consistent with multiple wakeup on FreeBSD-8.1. The heavily 
multi-threaded code that assumes that only one thread can be woken up by 
one pthread_cond_signal call crashes, and the only reasonable 
explanation so far is that more than one threads are actually being 
woken up.


Yuri


On 02/27/2011 12:54, Yuri wrote:

On FreeBSD-8.1 this page says:
The pthread_cond_signal() function unblocks one thread waiting for the 
condition variable cond.


On Linux it says:
The /pthread_cond_signal/() function shall unblock at least one of the 
threads that are blocked on the specified condition variable /cond/ 
(if any threads are blocked on /cond/).


Also HP page 
(http://docs.hp.com/en/B2355-90130/pthread_cond_signal.3T.html) says: 
If there are no threads blocked on /cond/, this function has no 
effect. And later it says: It is possible that more than one thread 
can be unblocked due to a spurious wakeup.


This is quite confusing: in case nobody is waiting does it block or 
not? In case other threads are waiting it's really any arbitrary 
number of threads are woken up? Or on FreeBSD it's strictly 1? 
Shouldn't this be defined in one and only way by POSIX and all 
POSIX-compliant systems should work exactly the same.


I think man page should be expanded to give more comprehensive 
explanation.


Yuri
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to 
freebsd-hackers-unsubscr...@freebsd.org




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-02-27 Thread David Xu 
On 2011/02/28 05:26, Yuri wrote:
 Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion.
 
 Also I want to add that I came to this question while observing behavior
 consistent with multiple wakeup on FreeBSD-8.1. The heavily
 multi-threaded code that assumes that only one thread can be woken up by
 one pthread_cond_signal call crashes, and the only reasonable
 explanation so far is that more than one threads are actually being
 woken up.
 
 Yuri
 
 
 On 02/27/2011 12:54, Yuri wrote:
 On FreeBSD-8.1 this page says:
 The pthread_cond_signal() function unblocks one thread waiting for the
 condition variable cond.

 On Linux it says:
 The /pthread_cond_signal/() function shall unblock at least one of the
 threads that are blocked on the specified condition variable /cond/
 (if any threads are blocked on /cond/).

 Also HP page
 (http://docs.hp.com/en/B2355-90130/pthread_cond_signal.3T.html) says:
 If there are no threads blocked on /cond/, this function has no
 effect. And later it says: It is possible that more than one thread
 can be unblocked due to a spurious wakeup.

 This is quite confusing: in case nobody is waiting does it block or
 not? In case other threads are waiting it's really any arbitrary
 number of threads are woken up? Or on FreeBSD it's strictly 1?
 Shouldn't this be defined in one and only way by POSIX and all
 POSIX-compliant systems should work exactly the same.

 I think man page should be expanded to give more comprehensive
 explanation.

 Yuri
 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to
 freebsd-hackers-unsubscr...@freebsd.org


It is really not important if pthread_cond_signal wake up one thread
or multiple threads in corner case, because POSIX said:
---
When using condition variables there is always a Boolean predicate
involving shared variables associated with each condition wait that is
true if the thread should proceed. Spurious wakeups from the
pthread_cond_timedwait() or pthread_cond_wait() functions may occur.
Since the return from pthread_cond_timedwait() or pthread_cond_wait()
does not imply anything about the value of this predicate, the predicate
should be re-evaluated upon such return.
---

I think in normal case, pthread_cond_signal will wake up one thread,
but other events for example, UNIX signal and fork() may interrupt
a thread sleeping in kernel, and cause pthread_cond_wait to return
to userland, this is called spurious wakeup, and other events, I
can not think of yet, but I believe they exist.

Regards,
David Xu
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-02-27 Thread Daniel Eischen 

On Feb 27, 2011, at 4:26 PM, Yuri y...@rawbw.com wrote:

 Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion.
 
 Also I want to add that I came to this question while observing behavior 
 consistent with multiple wakeup on FreeBSD-8.1. The heavily multi-threaded 
 code that assumes that only one thread can be woken up by one 
 pthread_cond_signal call crashes, and the only reasonable explanation so far 
 is that more than one threads are actually being woken up.

It depends on what you mean by wakeup.  More than one thread may unblock, but 
only one thread will have the mutex locked after wakeup.  If other threads 
awake (as allowed by POSIX), they will have to check the state protected by the 
mutex to see if they really should awake and continue  or if they should block 
again on the CV.  A wakeup from pthread_cond_wait() should not assume that he 
was the only thread awoken.

--
DE___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Is pthread_cond_signal(3) man page correct?

2011-02-27 Thread Pieter de Goeje 
On Sunday 27 February 2011 22:26:18 Yuri wrote:
 Also I want to add that I came to this question while observing behavior
 consistent with multiple wakeup on FreeBSD-8.1. The heavily
 multi-threaded code that assumes that only one thread can be woken up by
 one pthread_cond_signal call crashes, and the only reasonable
 explanation so far is that more than one threads are actually being
 woken up.

pthread_cond_signal() can indeed wake up more than one thread. That's why you 
should always wrap pthread_cond_wait() in a loop. For example a blocking 
queue could be implemented like this (pseudo code):

take() {
  pthread_mutex_lock(mutex);
  while(queue-empty()) {
pthread_cond_wait(cond, mutex);
  }
  item = queue-get();
  pthread_mutex_unlock(mutex);
  return item;
}

put(item) {
  pthread_mutex_lock(mutex);
  queue-put(item);
  pthread_cond_signal(cond);
  pthread_mutex_unlock(mutex);
}

pthread_cond_signal() itself never blocks.
Hope this helps.

-- 
Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org