Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c,comp.programming.threads Subject: Re: Trivial C11 threads.h wrapper (public domain) Date: Mon, 01 Oct 2012 15:19:28 -0700 Organization: None to speak of Lines: 40 Message-ID: References: <5065EAFD.1050102@loria.fr> <5068B604.9020606@web.de> <5068C9C3.6090502@loria.fr> <50696193.3090503@web.de> <506966CA.6080308@loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx04.eternal-september.org; posting-host="5842a546a2d4559ed11e9ac4721da702"; logging-data="9555"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195g6yJZQl2pUthZxShDpvT" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:7Ef3LBhl/OEYra3LYt0RymuurQI= sha1:RCGJHgboGtqTIzzNhvUDwRaLKsk= Xref: csiph.com comp.lang.c:26942 comp.programming.threads:1158 Jens Gustedt writes: [...] > The problem here is that this is not an interface that I/we design, > but that this is supposed to emulate a C library interface. The > description there is extremely concise, and in particular it doesn't > foresee the possibility of failure of the call. (For other functions > the standard would have some generic phrase "if you pass invalid input > to the function the behavior is undefined".) [...] I haven't studied C11's closely, but I do find the description of mtx_destroy() a bit troubling: Synopsis 1 #include void mtx_destroy(mtx_t *mtx); Description 2 The mtx_destroy function releases any resources used by the mutex pointed to by mtx. No threads can be blocked waiting for the mutex pointed to by mtx. Returns 3 The mtx_destroy function returns no value. So what does mtx_destroy() do if some thread *is* blocked waiting for mtx? I suppose the behavior is undefined by omission, but changing the word "can" to "shall" would have made that explicit. And why not define the behavior, more or less as POSIX does? Would detecting blocked threads be too difficult on some systems? -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"