This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] c++0x timed wait's in <condition_variable>


On Tue, Sep 23, 2008 at 4:28 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi again, Chris ,
>> This patch solves the issue with solution B.
>>
> I say, for gcc4.4.0, let's go ahead with Plan B. We can certainly
> improve things later.
>
> Only, please confirm that the additional exports are in any case needed
> if we want a separate monotonic clock, regtest again the patch vs
> current mainline and commit it.
>
> Thanks again,
> Paolo.
>

This issue is also discussed in DR 887 (not public yet I don't think,
check the lwg active issues list post San Fran). I spoke with Howard
H. and the intent of the wording is to allow user-defined clocks to be
used with condition variables given that cond var's may only work with
some "known" clock type(s). If a user calls wait_* with an unknown
clock type, then it must first be synced to the known clock.

We can currently say that condition_variable's known clock is
system_clock since we don't have the pthread_condattr_setclock backend
stuff in gthreads to allow the use of monotonic_clock. If a user
supplies a monotonic clock, it will just sync it to the system_clock
and all is good (except for a small sync issue if there's a large
delay between the two now() calls during syncing resulting in the
function exiting potentially later than intended. Howard thinks this
is unavoidable no matter how you specify it).

Attached updated patch. Tested x86_64 (with --enable-clock-gettime=rt).

Ok for mainline?

Chris

Attachment: cond_var.patch.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]