Posix Mutex: multiple lock within the same thread
unifire
I'm porting a Win32 application to the posix API (linux).
In the msdn documentation the EnterCriticalSection function is
described as follows
[...]
After a thread has ownership of a critical section, it can make
additional calls to EnterCriticalSection without blocking its
execution. T
This prevents a thread from deadlocking itself while waiting for a
critical section that it already owns.
[...]
Is there a posix attribut for the pthread_mutex_lock according to the
win32 behavior?
Many thanks!
unifire
unifire
I just found the solution:
PTHREAD_MUTEX_RECURSIVE
If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex shall
maintain the concept of a lock count. When a thread successfully
acquires a mutex for the first time, the lock count shall be set to
one. Every time a thread relocks this mutex, the lock count shall be
incremented by one. Each time the thread unlocks the mutex, the lock
count shall be decremented by one. When the lock count reaches zero,
the mutex shall become available for other threads to acquire. If a
thread attempts to unlock a mutex that it has not locked or a mutex
which is unlocked, an error shall be returned.
Bin Chen
Good design don't need recursive mutex.
http://zaval.org/resources/library/butenhof1.html
Randy Howard
(in article <1172278193.7...@s48g2000cws.googlegroups.com>):
I miss David's always excellent contributions to this group. I don't
know for sure, but I suspect the takeover of the group by a very few as
their own private mailing list on lock-free might have something to do
with his absence.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Chris Thomasson
news:0001HW.C20610C2...@news.verizon.net...
> On Fri, 23 Feb 2007 18:49:53 -0600, Bin Chen wrote
> (in article <1172278193.7...@s48g2000cws.googlegroups.com>):
> I miss David's always excellent contributions to this group. I don't
> know for sure, but I suspect the takeover of the group by a very few as
> their own private mailing list on lock-free might have something to do
> with his absence.
You mean SenderX?
http://groups.google.com/group/comp.programming.threads/msg/eec3f9383c5fb3f8
http://groups.google.com/group/comp.programming.threads/msg/2b4fd48827d37e28
http://groups.google.com/group/comp.programming.threads/msg/113d2d6f90563eda
(Some of Dave's thoughts on lock-free algorithms in general...)
BTW... Are you suggesting that questions and/or info on experimental
lock-free algorithms are out of place in comp.programming.threads? Well,
when STM gets going... Be prepared for this place to start receiving
questions on how to avoid and/or reduce livelock... Its going to really suck
around here then!
Anyway, I highly doubt that David was driven away from this group because
lock-free algorithms are discussed here by a few people!
:O
Dave Butenhof
> know for sure, but I suspect the takeover of the group by a very few as
> their own private mailing list on lock-free might have something to do
> with his absence.
In fact, going by the date of my last post I've been absent since
September... due to a bunch of factors. Busy time at work, a new school
year with my wife teaching full time so that I have to get the kids off
to the bus before I head in to work, both kids in various plays with a
lot of driving around and set construction... combined with a flaky news
server. (That is, in more practical terms, the flaky server kept me from
easily getting my news fix the way I like it, and the realization that I
really didn't have time for it anyway kept me from doing anything about
it until I eventually forgot even to try!)
I remembered again a few weeks ago, and after a few days of trying on
and off, the server responded; I skimmed over some of the new stuff but
didn't feel that any additional response was necessary. Then the server
went away for another week or so. It's been working OK for a few days
but I hadn't felt inclined to respond to anything.
But I guess I couldn't wish for a better (re-)entry cue. ;-)
As for lock-free... Chris' former alter-ego SenderX could be an
aggravating little zealot, but he had some good ideas and was great for
waking up the sleepy little discussion list. Those arguments were a lot
of fun. (And I don't mean to imply that Chris got boring when he dropped
the alias; I've always been glad we've got him.)
Everyone with interest in threads or parallelism ought to be paying
attention to lock-free, because it's important and is going to get more
important as the techniques get generalized and encapsulated and as
multi-core systems become essentially universal. We're reaching the end
of the days when anyone using lock-free will be researching and
implementing it themselves (which is good, because it's awfully easy to
get catastrophically wrong); but to use them effectively you should
still understand the principles. Especially if you're coding enterprise
server systems, lock-free is one of the important tools in your toolbox.
There have certainly been times when the newsgroup may seem to be
dominated by a particular group or interest; lock-free isn't the first
and hopefully won't be the last. If that's not your main interest, I
know that the inundation can get overwhelming at times. Be patient; over
time it all evens out, and you may have learned something that could
become valuable. Case in point... READING nearly everything (and
understanding much) of what goes past this newsgroup has helped greatly
to contribute to my illusion of expertise. ;-)
Anyway... "I'm back", and with luck the pesky little news server will
let me hang around.
Bin Chen
You wrote a long paragraph about your news server. But I don't know
why you not access the USENET thru google, it can be very stable and
easy to use. :-P
Dave Butenhof
> You wrote a long paragraph about your news server. But I don't know
> why you not access the USENET thru google, it can be very stable and
> easy to use. :-P
I've tried it. It's great for researching, but I don't like the
interface for POSTING. Granted, I haven't tried it in a long time, and
it may have improved. In any case, it's easy to spend a lot of my day
when I should be doing things for HP or my family following the
newsgroup and having fun pursuing arguments or writing long historical
explanations. There really wasn't enough time for that in my schedule,
and I was creating unnecessary stress trying to do everything at once.
The news server failure caused me to realize I needed a newsgroup
vacation. Everybody deserves one, once in a while. ;-)
Randy Howard
(in article <erukma$r9r$1...@usenet01.boi.hp.com>):
> In fact, going by the date of my last post I've been absent since
> September... due to a bunch of factors. Busy time at work, a new school
> year with my wife teaching full time so that I have to get the kids off
> to the bus before I head in to work, both kids in various plays with a
> lot of driving around and set construction... combined with a flaky news
> server. (That is, in more practical terms, the flaky server kept me from
> easily getting my news fix the way I like it, and the realization that I
> really didn't have time for it anyway kept me from doing anything about
> it until I eventually forgot even to try!)
>
> I remembered again a few weeks ago, and after a few days of trying on
> and off, the server responded; I skimmed over some of the new stuff but
> didn't feel that any additional response was necessary. Then the server
> went away for another week or so. It's been working OK for a few days
> but I hadn't felt inclined to respond to anything.
Having a reliable nntp connection for a while can make you take it for
granted. I certainly understand the parenting aspects as well. :-)
> But I guess I couldn't wish for a better (re-)entry cue. ;-)
Glad to hear you are doing well and back ...
> As for lock-free... Chris' former alter-ego SenderX could be an
> aggravating little zealot, but he had some good ideas and was great for
> waking up the sleepy little discussion list. Those arguments were a lot
> of fun. (And I don't mean to imply that Chris got boring when he dropped
> the alias; I've always been glad we've got him.)
>
> Everyone with interest in threads or parallelism ought to be paying
> attention to lock-free, because it's important and is going to get more
> important as the techniques get generalized and encapsulated and as
> multi-core systems become essentially universal. We're reaching the end
> of the days when anyone using lock-free will be researching and
> implementing it themselves (which is good, because it's awfully easy to
> get catastrophically wrong); but to use them effectively you should
> still understand the principles. Especially if you're coding enterprise
> server systems, lock-free is one of the important tools in your toolbox.
I'm interested to see how they might evolve such that the techniques
can be used in portable software development. Until such time, they
don't really do it for me, developing for multiple CPU architectures.
> There have certainly been times when the newsgroup may seem to be
> dominated by a particular group or interest; lock-free isn't the first
> and hopefully won't be the last.
Fair enough.
Chris Thomasson
[...]
> I'm interested to see how they might evolve such that the techniques
> can be used in portable software development. Until such time, they
> don't really do it for me, developing for multiple CPU architectures.
You can get away with using lock-free libraries if you wrap it all under a
common API that you design. This abstracts the libraries API. Your
application does not need to know anything about how the common API in
actually implemented. So, you can create lets say, a common API for a queue.
You can create two implementations of the queue. One in POSIX threads, the
other in x86 / SPARC / PowerPC or whatever assembly language. Then you can
freely interchange between the queue implementations. I guess what i trying
to say is that lock-free can be abstracted away into an interface as simple
as PThreads... Its rather trivial to create a lock-based version of a
lock-free algorithms.
Dave Butenhof
In theory, that's absolutely true. And in theory, there's no difference
between theory and practice. (Yeah, I know, I've used that one before; I
like it!)
The problem is that if the performance characteristics of the lock-based
algorithm are a good fit for your application, then the overhead of
designing, coding, and porting a lock-free version is wasted. And if you
really need the lock-free concurrency characteristics then you need to
start skewing the design of the calling code to minimize the impact of
the lock-based version where you haven't ported the lock-free version...
which means you don't use the lock-free version as it should be used
until you get rid of the lock-based version entirely.
Or, in other words... in PRACTICE, you generally either commit to
porting the lock-free package everywhere your application is going, or
you write your application to work acceptably with a lock-based package
and don't bother with the lock-free at all.
We dealt with this during early implementation of the CMA package,
across VAX, Alpha, and MIPS -- a MIPS R4000 (used for ULTRIX and early
OSF/1) that didn't have real atomic ops. Instead, there was a "test and
set" KERNEL syscall. Which can be transparently substituted for a real
atomic test and set instruction. Except you now either code for the
enormous call overhead of the syscall... or turn off the kernel thread
conditionals in the thread library and stick with a crufty user-mode
multiplexor that actually finishes a task in your lifetime until the
MIPS OSF/1 variant thankfully bites the dust... ;-)
Dave Butenhof
>> Everyone with interest in threads or parallelism ought to be paying
>> attention to lock-free, because it's important and is going to get more
>> important as the techniques get generalized and encapsulated and as
>> multi-core systems become essentially universal. We're reaching the end
>> of the days when anyone using lock-free will be researching and
>> implementing it themselves (which is good, because it's awfully easy to
>> get catastrophically wrong); but to use them effectively you should
>> still understand the principles. Especially if you're coding enterprise
>> server systems, lock-free is one of the important tools in your toolbox.
>
> I'm interested to see how they might evolve such that the techniques
> can be used in portable software development. Until such time, they
> don't really do it for me, developing for multiple CPU architectures.
That's a perfectly reasonable attitude to take. But also remember that
the people doing the research and early development now, helped at least
in some small way by the contribution of discussions on this newsgroup,
will (directly or otherwise) bring about the day when there ARE portable
bodies of lock-free code behind usable and standardized APIs that you
CAN use.
Randy Howard
(in article <BNOdnfM1oZ9e7XnY...@comcast.com>):
Sure, you can always slap a layer on and make details disappear,
nothing new there. Key thing is: I can put production code into use,
have it be stable, using tested and proven underlying implementations,
and not spend time writing assembler for a dozen different CPUs.
Or, I can stop producing what customers want, and spend ~forever
jacking around with lock-free on my own, while chasing my way through a
field of patent land-mines. Gee, why is that not lighting me up?
I've yet to encounter a situation where performance was problematic
with pthreads, in fact, it's often stunningly good, and clients are
more than happy. Even using pthreads-win32 for those evil little
Windows boxes instead of the incredibly crufty windows threading api.
So as far as lock-free goes, I'm glad others are researching it, but I
haven't needed it for my own projects, and as systems continue to get
faster, I need it even less all the time.
I'm sure there are classes of problems where it is needed, and for
which it makes a lot of sense, but I've yet to encounter even one
example in practice.
Randy Howard
(in article <es2e5q$uah$1...@usenet01.boi.hp.com>):
> Or, in other words... in PRACTICE, you generally either commit to
> porting the lock-free package everywhere your application is going, or
> you write your application to work acceptably with a lock-based package
> and don't bother with the lock-free at all.
Indeed, you said it better, but I read this after replying to Chris.
Randy Howard
(in article <es2eap$uah$2...@usenet01.boi.hp.com>):
Of course, I am fully aware of that, and as I said in the response to
Chris I just posted, I am glad that work is going on, and hope that it
yields (no pun intended) good things down the road.
Chris Thomasson
[...]
>
> Sure, you can always slap a layer on and make details disappear,
> nothing new there.
;^)
> Key thing is: I can put production code into use,
> have it be stable, using tested and proven underlying implementations,
> and not spend time writing assembler for a dozen different CPUs.
Well, pick two or three architecture that you think might benefit from some
a dash of lock-free flavored spices here and there... Of course, well, if
you have the time to do this sort of thing. IMHO, it basically worth in the
long run at least... :O
>
> Or, I can stop producing what customers want, and spend ~forever
> jacking around with lock-free on my own,
:O
> while chasing my way through a
> field of patent land-mines. Gee, why is that not lighting me up?
Well, sometimes you have to pay for what you use... If you find a very
usefull and non-trivial patent, why not think about licensing it... Well, if
you think the patent is crap, try to do better on your own... If you can't,
well, why is the licensing of a patent all that bad?
For instance, what wrong with somebody patenting the following algorithms:
http://groups.google.com/group/comp.arch/browse_frm/thread/24c40d42a04ee855
http://groups.google.com/group/comp.arch/browse_frm/thread/b2f751d5dad6c07b
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/65c9c2673682d4cf
Why, you want to use them for free in commercial products?
Randy Howard
(in article <QfmdnbBIqb1g23vY...@comcast.com>):
> "Randy Howard" <randy...@FOOverizonBAR.net> wrote in message
> news:0001HW.C20B2B34...@news.verizon.net...
> [...]
>> Key thing is: I can put production code into use,
>> have it be stable, using tested and proven underlying implementations,
>> and not spend time writing assembler for a dozen different CPUs.
>
> Well, pick two or three architecture that you think might benefit from some
> a dash of lock-free flavored spices here and there...
That's just it. I can't think of of a need for them for anything on
any platform at the time being. If by some miracle I need them in an
application down the road, I'll amuse myself that way at that time.
> Of course, well, if you have the time to do this sort of thing. IMHO, it
> basically worth in the long run at least... :O
Apart from educational value, it's not worth it at all, unless there is
a solid need for it.
>> Or, I can stop producing what customers want, and spend ~forever
>> jacking around with lock-free on my own,
>
>> O
>
>> while chasing my way through a
>> field of patent land-mines. Gee, why is that not lighting me up?
>
> Well, sometimes you have to pay for what you use... If you find a very
> usefull and non-trivial patent, why not think about licensing it... Well, if
> you think the patent is crap, try to do better on your own... If you can't,
> well, why is the licensing of a patent all that bad?
It's not bad per se, although I think patents for software are pretty
much BS. That said, /if/ I had a need for something that was patented,
I would of course license it properly, but how you ever to know for
sure, because I don't have the time to read every single software
patent to see if I might be violating one somehow. This is the problem
with them, you can develop everything in a clean room, and still be
guilty of something, and never know it until a lawyer knocks on the
door.