From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55019 invoked by alias); 27 Mar 2017 13:29:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 54925 invoked by uid 89); 27 Mar 2017 13:29:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=questioning, 479, acquire X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AF09565CFF Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=triegel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com AF09565CFF Message-ID: <1490607253.26906.430.camel@redhat.com> Subject: Re: [PATCH v3 0/6] Add support for ISO C11 threads.h From: Torvald Riegel To: Adhemerval Zanella Cc: Joseph Myers , libc-alpha@sourceware.org, Martin Sebor In-Reply-To: <75c9a3ae-5f8f-3726-c3d9-d0d3b682a899@linaro.org> References: <1490103612-9401-1-git-send-email-adhemerval.zanella@linaro.org> <662cb906-1845-1164-5b61-a575c5edfe07@linaro.org> <75c9a3ae-5f8f-3726-c3d9-d0d3b682a899@linaro.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Mar 2017 13:29:00 -0000 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00616.txt.bz2 On Tue, 2017-03-21 at 17:09 -0300, Adhemerval Zanella wrote: > 405: The mutex specification > > "The C11 specification of mutexes is missing the total order over all the > calls on a particular mutex." > > My understanding is current implementation with POSIX primitives should be > enough to guarantee C11 total order over mutex (which is currently based on > acquire/release semanthics). Yes. > 414: Typos in 6.27 Threads > > The typos does clarify one definition of mtx_plain and raises a questioning: > how should we proceed if mtx_timedlock is used along with a mtx_plain mutex? If C11 requires that mtx_timedlock is supplied a mutex that supports timeout. If the program violates this requirement, it is undefined behavior, and glibc is allowed to just acquire with a timeout. > 469: lock ownership vs. thread termination See my other response to this thread. > > 470: mtx_trylock should be allowed to fail spuriously > > It align with POSIX and thus with __pthread_mutex_trylock which uses a > atomic_compare_and_exchange_bool_acq (similar to atomic_compare_exchange_weak). That's not quite true. See my other response. > 479: unclear specification of mtx_trylock on non-recursive muteness > 480: cnd_wait and cnd_timewait should allow spurious wake-ups See my other response to this thread.