To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=44627
------- Additional comments from [EMAIL PROTECTED] Thu Mar 10 01:51:14 -0800
2005 -------
mhu: The avoiding spurious wake-up situation is perfect - I have no problems
with that while loop.
My major beef is with:
- while ( ! pCond->m_State )
+ if ( ! pCond->m_State )
{
if ( pTimeout )
{
ie. Currently - given that most conditions are strobed set/reset etc. - and this
is quite normal; there is no garentee that osl_waitCondition will ever complete
with the above loop.
Semantically our use of this code can be collapsed to:
Thread 1 Thread 2
condition.wait() -> pthread_cond_timedwait
condition.set()
... [ do work ] ... [ shorter than the (1 sec) timeout ]
condition.reset()
... [ long block ] wake up,
while (! pCond->m_State )
back to pthread_cond_timewait [ 1 second ]
Of course the 'do work' can be rather quick - ie. unlikely to be scheduled in
that slot, the 'long block' is an ideal schedule point (hit poll etc.).
ie. in summary - yes, immediately re-setting the condition is crazy ;-) but
after removing that the symptoms persist - since the 'work' part of this takes
less time than the timeout.
What we really need is to be sure: when we 'set' a condition, that any waiting
threads _will_ be woken; and indeed they are - but the while (! pCond->m_State )
introduces a race - whereby this "wake once" state [synchronised by the O/S ] is
essentially thrown away in favour of the current state of this member variable -
IMHO that is a bug.
If you compare with the Win32 implementation:
switch ( WaitForSingleObject( (HANDLE)Condition, timeout ) )
{
case WAIT_OBJECT_0:
return (osl_cond_result_ok);
case WAIT_TIMEOUT:
return (osl_cond_result_timeout);
default:
return (osl_cond_result_error);
}
There is no equivalent check for the local state [ ok - so I havn't read the
reference, and perhaps the Win32 thing is broken-by-design to behave like this
oslCondition on Unix - but I'd find it hard to believe; it's pretty unusable
behavior IMHO ].
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
