|
Home > Archive > Unix Programming > October 2004 > 'Java-like' synchronization for pthreads with C++.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
'Java-like' synchronization for pthreads with C++.
|
|
| RJGraham 2004-09-15, 10:36 am |
| Hello,
I'm developing a multi threaded C++ app under Linux using pthreads and
would like to have 'java-like'synchronization for critical sections of
code. In other words, while a thread holds a lock on a resource, the
same thread should be able to reacquire the same lock without blocking
(while still holding the lock).
I have currently implemented a simple binary lock class using ipc
semaphores that allows a single thread to grab and release a lock around
a critical section. This works as intended to block other threads, but
also blocks if the same thread tries to grab the lock while still
holding it (I can post the code for this class if it would help).
To achieve the result I'm looking for, I think I need to modify my
binary lock class to capture a handle to the thread that grabs the lock
and compare it against the thread handle for subsequent grab attempts.
If the thread already owns the lock, it doesn't block.
I don't have much experience with IPC-Linux and have scanned the IPC man
pages for semget, pthread_* , etc, but don't see an api function that
will return a handle to the current thread.
So I guess my questions are:
1) How do I get a 'handle' to the current thread so I can check to see
if the same thread is trying to reacquire a lock?
2) Is there a better solution to this problem?
Thanks for any help.
-Randy
| |
| RJGraham 2004-09-15, 10:36 am |
|
>
> 1) How do I get a 'handle' to the current thread so I can check to see
> if the same thread is trying to reacquire a lock?
>
Of course, just after posting this I found 'pthread_self().
So I think question 1) is answered ;)
-Randy
| |
| Måns Rullgård 2004-09-15, 10:36 am |
| RJGraham <null@null.com> writes:
>
> Of course, just after posting this I found 'pthread_self().
>
> So I think question 1) is answered ;)
You might also want to read about recursive mutexes.
--
Måns Rullgård
mru@mru.ath.cx
| |
| RJGraham 2004-09-15, 10:36 am |
| Måns Rullgård wrote:
>
> You might also want to read about recursive mutexes.
>
Thank you, that is exactly what I need.
-Randy
| |
| David Schwartz 2004-09-29, 8:09 pm |
|
"RJGraham" <null@null.com> wrote in message
news:WLedndfsQM163NrcRVn_vA@giganews.com...
> Måns Rullgård wrote:
[vbcol=seagreen]
> Thank you, that is exactly what I need.
Let me give you my generic "don't do that" speech about recursive
mutexes...
Recursive mutexes are bad. It's impossible to write code that can work
sanely without knowing what mutuxes it holds. If it knows what mutexes it
holds, it can just refrain from acquiring a mutex it knows that it already
holds.
DS
| |
| Måns Rullgård 2004-09-29, 8:09 pm |
| "David Schwartz" <davids@webmaster.com> writes:
> "RJGraham" <null@null.com> wrote in message
> news:WLedndfsQM163NrcRVn_vA@giganews.com...
>
>
>
>
> Let me give you my generic "don't do that" speech about recursive
> mutexes...
>
> Recursive mutexes are bad. It's impossible to write code that can work
> sanely without knowing what mutuxes it holds. If it knows what mutexes it
> holds, it can just refrain from acquiring a mutex it knows that it already
> holds.
Agreed. I have never used a recursive mutex, and never seen a
situation that would benefit from one.
--
Måns Rullgård
mru@mru.ath.cx
| |
| RJGraham 2004-10-03, 2:48 am |
| > Recursive mutexes are bad. It's impossible to write code that can work
> sanely without knowing what mutuxes it holds. If it knows what mutexes it
> holds, it can just refrain from acquiring a mutex it knows that it already
> holds.
>
> DS
Which is exactly what I was asking for.
Are you familiar with Java synchronization?
-Randy
| |
| Måns Rullgård 2004-10-03, 2:48 am |
| "RJGraham" <spamcop_764376_@surfbytes_123_._5637.com_4785> writes:
>
> Which is exactly what I was asking for.
>
> Are you familiar with Java synchronization?
Yes. The conclusion is that Java is bad, and can not work sanely.
This is pretty much in line with my experience using java.
--
Måns Rullgård
mru@mru.ath.cx
| |
| Jonathan Adams 2004-10-03, 2:48 am |
| In article <X8udnQulyKEREsLcRVn-sA@giganews.com>,
"RJGraham" <spamcop_764376_@surfbytes_123_._5637.com_4785> wrote:
>
> Which is exactly what I was asking for.
No, it isn't -- you're asking for the mutex primitives to allow
recursive acquiring. He's pointing out that that can lead to bad code,
since (for example) you can call state-changing functions without having
to think about it.
Basically, since the coder must always know what locks are being held to
correctly write an MT application, and recursive mutexes encourage and
support coding styles which obscure that information, they're a bad idea
in maintainable code.
> Are you familiar with Java synchronization?
Yes, and I think it sacrificed clarity, maintainability, and performance
for a misguided "simplicity".
Cheers,
- jonathan
|
|
|
|
|