Reader/Writer-Mutex
David Butenhof
> I've written a multiple-reader/one-writer-mutex which allows to have
> timeouts for the mutex lock/unlock-operations. When there's no conten-
> tion between readers and writers or one writer and another writer, my
> implementation is only slightly less efficient than a rw-mutex with no
> timeouts. But I'm very very skeptical if there would be any useful app-
> lication for the timeout-opton. Can anyone convince me to keep that op-
> tion by giving an example of such a useful application ? *g*
POSIX read-write locks already have timeouts, courtesy of the POSIX
1003.1d-2000 amendment. That amendment has been merged into the POSIX
1003.1-2001 release, which is also the Single UNIX Specification, Version
3.
For most programs, they're not really useful at all because the application
has not useful strategy to deal with failure. However, for robust realtime
applications with hard deadlines and careful failsafe recovery code, such
capability can be critical.
So the question for you to consider would be whether you feel that your
package is likely to be used in any environment where the application is
likely to be able to take advantage of the timeout -- and whether the
"slightly less efficient" implementation is acceptable for applications
that don't need the timeout?
--
/--------------------[ David.B...@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/
Alexander Terekhov
David Butenhof wrote:
[...]
> So the question for you to consider would be whether you feel that your
> package is likely to be used in any environment where the application is
> likely to be able to take advantage of the timeout -- and whether the
> "slightly less efficient" implementation is acceptable for applications
> that don't need the timeout?
Do you know why PTHREAD_TIMEOUT_ALLOWED/PTHREAD_TIMEOUT_DISALLOWED
stuff was ditched? (I mean: "The pthread_mutex_timedlock() function
can be used only with mutexes whose timeout-allowed attribute is set
to PTHREAD_TIMEOUT_ALLOWED. The timeout-allowed attribute was
introduced under the Timeouts option as a performance-preserving
mechanism. An application programmer can set the timeout-allowed
attributes of selected mutexes to PTHREAD_TIMEOUT_DISALLOWED to avoid
the overhead associated with the mutexes being set up to handle timed
locks.")
regards,
alexander.
David Butenhof
It wasn't "ditched" because as far as I know it never existed, was never
proposed, nor even considered by the committees involved. (The original
definition occurred in 1003.4 while I was spending most of my POSIX time in
1003.14/18 -- but we were consulted fairly early, and I followed 1003.1d
and especially the timer stuff reasonably closely. This isn't to say that I
couldn't possibly have missed some temporary furor over something like
this, but I rather doubt it.)
There was a big controversy over whether mutex timeouts should even be
specified given the possible overhead. And the interface was optional
because some (perhaps most) implementations wouldn't want to be burdened
with it.
Alexander Terekhov
David Butenhof wrote:
[...]
> > Do you know why PTHREAD_TIMEOUT_ALLOWED/PTHREAD_TIMEOUT_DISALLOWED
> > stuff was ditched? (I mean: "The pthread_mutex_timedlock() function
> > can be used only with mutexes whose timeout-allowed attribute is set
> > to PTHREAD_TIMEOUT_ALLOWED. The timeout-allowed attribute was
> > introduced under the Timeouts option as a performance-preserving
> > mechanism. An application programmer can set the timeout-allowed
> > attributes of selected mutexes to PTHREAD_TIMEOUT_DISALLOWED to avoid
> > the overhead associated with the mutexes being set up to handle timed
> > locks.")
>
> It wasn't "ditched" because as far as I know it never existed, was never
> proposed, nor even considered by the committees involved.
http://www.usenix.org/publications/login/standards/22.posix.html
(A Programmer's Overview of the POSIX.1d Draft Standard: Additional
Realtime Extensions)
> (The original
> definition occurred in 1003.4 while I was spending most of my POSIX time in
> 1003.14/18 -- but we were consulted fairly early, and I followed 1003.1d
> and especially the timer stuff reasonably closely. This isn't to say that I
> couldn't possibly have missed some temporary furor over something like
> this, but I rather doubt it.)
regards,
alexander.
SenderX
> ficantly more complex
http://appcore.home.comcast.net/src/ReadWriteSection.c
Simple, timeouts, 100% lock-free reading, and very fast.
--
The designer of the SMP and HyperThread friendly, AppCore library.
http://AppCore.home.comcast.net
Thomas...@gmx.li
> Simple, timeouts, 100% lock-free reading, and very fast.
You're a moron; no one needs your buggy and undocumented coding.
SenderX
My library is experimental, anyway... Nobody is interested in working
lock-free sync code?
You must have found a bug in my read / write section, where is it exactly? I
don't see any bugs in my current read write section...
I would like you to show me some error reproduction code, please.
If you don't have any, or can't show me where the bug is, then you sir...
Are a moron, indeed.
> undocumented coding.
Docs are coming.
By the way, you got any good lock-free sync. to share with anybody...
Anybody at all?
P.S.
Its not a crime to post working test code, so others can tinker with it.
David Schwartz
"SenderX" <x...@xxx.xxx> wrote in message
news:BhHOa.11996$H17.4047@sccrnsc02...
> > no one needs your buggy...
> My library is experimental, anyway... Nobody is interested in working
> lock-free sync code?
> Its not a crime to post working test code, so others can tinker with it.
Your original post read, in its entirety (except for the URL and an
unrelated signature):
>> The code for a multiple-reader/one-writer-mutex with timeouts is signi-
>> ficantly more complex
> Simple, timeouts, 100% lock-free reading, and very fast.
I don't see any mention of your code being experimental or "working test
code". You mislead people so often regarding the status of your code that
it's clear to me that either you're on a malicious question to mislead the
unwary or you don't really believe that your code is dangerous and don't
take seriously the hazzards that have been tediously explained to you.
DS
SenderX
"This code is a work in progress and may be subject to radical change."
Anyway, my signature should be more clear now.
;)
A 100% win32-free, pthreads version of my lock-free sync. is on its way...
That should open AppCore up to a lot more people.
--
The designer of the experimental, SMP and HyperThread friendly, AppCore
library.
http://AppCore.home.comcast.net
Alexander Terekhov
SenderX wrote:
>
> On the front page of my site, there is a clause...
>
> "This code is a work in progress and may be subject to radical change."
>
> Anyway, my signature should be more clear now.
http://www.godtheband.com/html/essay/Defending_GOD.htm
>
> ;)
regards,
alexander.
David Schwartz
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3F0B467A...@web.de...
> http://www.godtheband.com/html/essay/Defending_GOD.htm
What kind of an idiot fabricates evidence that makes him look guilty?!
DS
PS: That was a rhetorical question.
David Butenhof
>> It wasn't "ditched" because as far as I know it never existed, was never
>> proposed, nor even considered by the committees involved.
>
> http://www.usenix.org/publications/login/standards/22.posix.html
> (A Programmer's Overview of the POSIX.1d Draft Standard: Additional
> Realtime Extensions)
Fascinating. Well, Alexander, sometimes it's nice to have a "master of the
google" on hand. I certainly have no basis to dispute the contents of this
paper. However, it references 1003.1d/D11 and while I don't have a copy of
D11 handy none of this TIMEOUT_ALLOWED stuff existed in draft 10, nor in
the final amendment. Since the final version was D14, those may have
existed for up to a year or so between mid-1998 and and mid-1999.
Had I been following 1003.1d when they added this silly attribute I would
have objected. Since it was removed, clearly there were plenty of others
with sense available. ;-) The critical aspect of mutex performance is in
the NONBLOCKING case, where timeout is irrelevant. The cost of setting up
for a timeout on the blocking path is tiny compared to the scheduling
operations, and would only occur when calling pthread_mutex_timedlock().
(Which presumably one would never do on a mutex that would have been set
PTHREAD_TIMEOUT_DISALLOWED.)
Alexander Terekhov
David Butenhof wrote:
>
> Alexander Terekhov wrote:
>
> >> It wasn't "ditched" because as far as I know it never existed, was never
> >> proposed, nor even considered by the committees involved.
> >
> > http://www.usenix.org/publications/login/standards/22.posix.html
> > (A Programmer's Overview of the POSIX.1d Draft Standard: Additional
> > Realtime Extensions)
>
> Fascinating. Well, Alexander, sometimes it's nice to have a "master of the
> google" on hand.
Ha! I wish you'd try to explain it to Boost moderators. They've
recently "quarantined" me again (for the 3rd time, actually) for
excessive links usage. (Sorry, I also just can't resist and not
share the latest rejected boost message of mine with the audience
here; see below; if you want).
> I certainly have no basis to dispute the contents of this
> paper. However, it references 1003.1d/D11 and while I don't have a copy of
> D11 handy none of this TIMEOUT_ALLOWED stuff existed in draft 10, nor in
> the final amendment. Since the final version was D14, those may have
> existed for up to a year or so between mid-1998 and and mid-1999.
>
> Had I been following 1003.1d when they added this silly attribute I would
> have objected. Since it was removed, clearly there were plenty of others
> with sense available. ;-) The critical aspect of mutex performance is in
> the NONBLOCKING case, where timeout is irrelevant. The cost of setting up
> for a timeout on the blocking path is tiny compared to the scheduling
> operations, and would only occur when calling pthread_mutex_timedlock().
> (Which presumably one would never do on a mutex that would have been set
> PTHREAD_TIMEOUT_DISALLOWED.)
The point is that a mere presence of timedlock() may slow down
pthread_mutex_unlock(), for example. You might want to (well, I
know that you, David, surely won't do it ;-) ) take a brief look
at pthreads-win32...
regards,
alexander.
<Forward Quoted>
******
Received: from [129.79.245.244] (helo=heart-of-gold.osl.iu.edu)
by mx24.web.de with esmtp (WEB.DE 4.99 #394)
id 19a9hd-0004wH-00
for tere...@web.de; Wed, 09 Jul 2003 09:49:25 +0200
Received: from heart-of-gold.osl.iu.edu (localhost.localdomain [127.0.0.1])
by heart-of-gold.osl.iu.edu (8.11.6/8.11.6) with ESMTP id h697nO403552
for ; Wed, 9 Jul 2003 02:49:24 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Your message to Boost awaits moderator approval
From: boost-...@lists.boost.org
To: tere...@web.de
Message-ID:
Date: Wed, 09 Jul 2003 02:49:22 -0500
Precedence: bulk
X-BeenThere: bo...@lists.boost.org
X-Mailman-Version: 2.1b3
X-List-Administrivia: yes
List-Id: Boost mailing list
Errors-To: boost-...@lists.boost.org
Sender: boost-...@lists.boost.org
boost-...@lists.boost.org schrieb am 09.07.03 09:49:25:
>
> Your mail to 'Boost' with the subject
>
> Re: Updated Boost.Random to TR proposal
>
> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
> Posts by member are currently quarantined for moderation
>
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision. If you would like to cancel
> this posting, please visit the following URL:
>
> http://lists.boost.org/mailman/confirm.cgi/boost/c6443c3c8fefae549f84c32b37bc41d0f3602677
>
******
<Forward Quoted>
******
Received: from [129.79.245.244] (helo=heart-of-gold.osl.iu.edu)
by mx17.web.de with esmtp (WEB.DE 4.99 #394)
id 19aCCJ-0000Cs-00
for tere...@web.de; Wed, 09 Jul 2003 12:29:15 +0200
Received: from heart-of-gold.osl.iu.edu (localhost.localdomain [127.0.0.1])
by heart-of-gold.osl.iu.edu (8.11.6/8.11.6) with ESMTP id h69ATE404100
for ; Wed, 9 Jul 2003 05:29:14 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Request to mailing list Boost rejected
From: boost-...@lists.boost.org
To: tere...@web.de
Message-ID:
Date: Wed, 09 Jul 2003 05:29:12 -0500
Precedence: bulk
X-BeenThere: bo...@lists.boost.org
X-Mailman-Version: 2.1b3
X-List-Administrivia: yes
List-Id: Boost mailing list
Errors-To: boost-...@lists.boost.org
Sender: boost-...@lists.boost.org
boost-...@lists.boost.org schrieb am 09.07.03 12:29:15:
>
> Your request to the Boost mailing list
>
> Posting of your message titled "Re: Updated Boost.Random to TR
> proposal"
>
> has been rejected by the list moderator. The moderator gave the
> following reason for rejecting your request:
>
> "No reason given"
>
> Any questions or comments should be directed to the list administrator
> at:
>
> boost...@lists.boost.org
******
<Forward Inline>
-------- Original Message --------
Message-ID: <3F0BC8B9...@web.de>
Newsgroups: gmane.comp.lib.boost.devel
Subject: Re: Updated Boost.Random to TR proposal
References: ... <beflon$iop$1...@main.gmane.org>
Joe Gottman wrote:
>
> "David Abrahams" <da...@boost-consulting.com> wrote in message >
> > Neal,
> >
> > I don't think Jens has had much time for this stuff and now that the
> > proposal is accepted most of the discussion has been taking place on
> > the committee standard libraries reflector. I suggest you post your
> > questions there.
> >
>
> Could you post a web address for the committee standard libraries
> reflector? I'd be interested in reading some of their comments, if
> they are open to the public.
No way. These are committee's trade secrets.
http://google.com/groups?selm=3ca675a5.27750256%40news.earthlink.net
(Subject: Re: ansi/iso latest info ?)
<quote>
That may be asking too much. You can get it for the price
of membership. It might be nice to have all of the flame
wars in the committee mailing lists archived for public
view, but that would only help those of us who want to
learn from it. Making it public could hinder those involved.
</quote>
Oh, by the way, speaking of C++ and "intellectual capital"...
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2877578,00.html
<quote author="Darl McBride" when=2002>
We get several dozen requests a month just to come in and see AIX
or HP-UX code base. And C++ programming languages, we own those,
have licensed them out multiple times, obviously. We have a lot of
royalties coming to us from C++. It was interesting to see the
depth of Caldera's intellectual capital.
</quote>
http://www.mozillaquest.com/Linux03/ScoSource-02_Story03.html#C++_Issues
<quote>
C++ Issues
MozillaQuest Magazine: C++ appears to be one of the properties
that SCO acquired through Novell's acquisition of AT&T's UNIX
Systems Laboratories and subsequent purchase of Novell's UNIX
interests by SCO. At this time most Linux and/or GNU/Linux
distributions include C++ compilers and editors. Is this
something for which SCO currently charges? If so, just what
are the current arrangements? If not, will C++ licensing and
enforcement be added to SCO's licensing and enforcement program?
Blake Stowell: C++ is one of the properties that SCO owns today
and we frequently are approached by customers who wish to license
C++ from us and we do charge for that. Those arrangements are
done on a case-by-case basis with each customer and are not
disclosed publicly. C++ licensing is currently part of SCO's
SCOsource licensing program.
MozillaQuest Magazine: How about GNU C++? Does GNU C++ use
SCO IP? If so, could SCO license and/or charge for use of its
IP in GNU C++?
Blake Stowell: I honestly don't know.
MozillaQuest Magazine: Does the C++ that currently is included
in most if not all Linux distributions contain SCO IP?
(a) If so, is that being done with or without SCO
permissions/licensing?
(b) If so, what impact/affect does this have on the ability
of people to freely distribute and use copies of those
Linux distributions? (Under GNU licensing, anyone may
make as many copies of a GNU/Linux distribution as they
please, freely distribute them for no charge and/or for
a charge, and use a GNU/Linux on as many computes as they
please -- at no charge. Etc.)
Blake Stowell: Again, I don't know. That's something we would
have to research.
</quote>
``Be afraid. Be very afraid.''
regards,
alexander.
P.S. Does anyone here know whether Microsoft was smart enough to include
C++ (in addition to a rather mysterious "applications interface layer")
in their recent license agreement with SCO ? Um, Herb are you here?
http://www.byte.com/documents/s=8276/byt1055784622054/0616_marshall.html
(SCO Owns Your Computer: "All Your Base Are Belong To Us", ...)
Randy Howard
> <Forward Quoted>
>
> ******
> Received: from [129.79.245.244] (helo=heart-of-gold.osl.iu.edu)
> by mx24.web.de with esmtp (WEB.DE 4.99 #394)
It's a landmark day. Did anyone else notice that the only links
in an entire post by Alexander were contained in included text
from previous usenet and email messages? I'm not sure I've
ever seen that happen before. :-)
--
Randy Howard
remove the obvious bits from my address to reply.
Alexander Terekhov
Randy Howard wrote:
>
> In article <3F0C0F9E...@web.de>, tere...@web.de says...
> > <Forward Quoted>
> >
> > ******
> > Received: from [129.79.245.244] (helo=heart-of-gold.osl.iu.edu)
> > by mx24.web.de with esmtp (WEB.DE 4.99 #394)
> .....
>
> It's a landmark day. Did anyone else notice that the only links
> in an entire post by Alexander were contained in included text
> from previous usenet and email messages? I'm not sure I've
> ever seen that happen before. :-)
Yeah. Strange things happen. That was just a blip. And I'm sorry.
regards,
alexander.