http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* Library requirement for mutex destroy - 5 messages, 4 authors
http://groups.google.com/group/comp.programming.threads/t/4a94e9df8d2f3e22?hl=en
==============================================================================
TOPIC: Library requirement for mutex destroy
http://groups.google.com/group/comp.programming.threads/t/4a94e9df8d2f3e22?hl=en
==============================================================================
== 1 of 5 ==
Date: Thurs, Oct 29 2009 3:25 pm
From: "Chris M. Thomasson"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:hccn64$fi5$2@news.eternal-september.org...
>
> "Noob" <root@127.0.0.1> wrote in message news:hcbsu6$ocf$1@aioe.org...
>> Chris M. Thomasson wrote:
>>
>>> Man! This sucks!! Anyway, I believe you could meet all the requirements,
>>> however, it's not going to be pretty. Here is what I hacked together for
>>> you so far:
>>>
>>> http://cpt.pastebin.com/f540aaef5
>>
>> Thanks Chris, I'll take a hard look at it.
>
> Here is updated code which handles the case in which a thread tries to
> unlock a mutex that is locked by another thread:
>
>
> http://cpt.pastebin.com/f3044e915
>
>
> It also fixes a race-condition I overlooked. The unlocking needs to be
> done under the protection of the hash lock. The previous code did not do
> this, which would allow a thread A to destroy the mutex just before a
> thread B unlocked it.
>
> Sorry about that non-sense!
>
>
> Anyway, I cannot seem to find any more issues.
I have implemented the algorithm in Relacy Race Detector:
http://relacy.pastebin.com/f227e4245
Relacy likes it! So, this scheme works. BTW, what does the interface look
like for the ST OS21 operating system? If it's compatible, then you have a
complete solution which will conform to the libraries rules.
== 2 of 5 ==
Date: Fri, Oct 30 2009 2:40 am
From: David Schwartz
On Oct 29, 5:42 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> A more probable conjecture would be that the library uses the
> delete-operation to detect if a mutex has meanwhile been unlocked
> without blocking on it and another conjecture based on that and a
> short search of the as-always-inaccessible relevant documentation[*]
> would be that (at least some versions of) Windows behaves in this way.
I don't see how that could make sense. What if the mutex has meanwhile
been unlocked but another thread is about to lock it? How do you
guarantee that this other thread doesn't lock some other mutex?
(Unless you add all the other crufty requirements, like that a mutex
handle cannot be a pointer and that they cannot be re-used.)
DS
== 3 of 5 ==
Date: Fri, Oct 30 2009 2:54 am
From: Rainer Weikusat
David Schwartz <davids@webmaster.com> writes:
> On Oct 29, 5:42 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
>> A more probable conjecture would be that the library uses the
>> delete-operation to detect if a mutex has meanwhile been unlocked
>> without blocking on it and another conjecture based on that and a
>> short search of the as-always-inaccessible relevant documentation[*]
>> would be that (at least some versions of) Windows behaves in this way.
>
> I don't see how that could make sense. What if the mutex has meanwhile
> been unlocked but another thread is about to lock it? How do you
> guarantee that this other thread doesn't lock some other mutex?
Because there are is one thread with a mutex or maybe n threads with
mutexes and one 'master thread' 'watching' them (or something similar
with clearly separated 'kinds of threads'). That's a possible
arrangement where the delete-semantics would make (some) sense. Other
arrangements are conceivable but people usually write code to
accomplish something definite and not because they are out of their
senses (often both to a degree, actually -- once something has
been implemented, it is all too clear how it should have been done
instead :->, but 'it works' is a very practical quality).
== 4 of 5 ==
Date: Fri, Oct 30 2009 11:33 am
From: "Chris M. Thomasson"
"David Schwartz" <davids@webmaster.com> wrote in message
news:6b9a4262-aaab-4ea4-9fa0-56d98ae49f58@g22g2000prf.googlegroups.com...
On Oct 28, 8:04 am, Noob <r...@127.0.0.1> wrote:
> > >> If delete is called on a locked mutex, the function must return an
> > >> error
> > >> code to signal the error to the function's caller.
> > > That is, IMO, fundamentally busted behavior, unless it only means
> > > locked by the calling thread.
> > Could you expand on /why/ you think it is busted behavior?
> > (I need ammo to try to convince the library authors.)
> Either they rely on this behavior or they don't. If they don't rely on
> it, why do they make you implement it? If they do rely on it, what
> happens when one thread destroys a mutex a split-second before another
> thread acquires it?
> The only way to make that sensible is to insist you detect an attempt
> to lock a destroyed mutex. However, think about what this means. It
> means you can never, ever reuse a mutex's identifier. It means a mutex
> cannot be a pointer to a structure that is freed when that mutex
> ceases to exist.
Indeed. The hack I posted also requires that the memory which makes up a
mutex cannot be freed. However, one can definetely use reference counting
with strong thread saftey to handle this senerio:
_________________________________________________________
struct foo
{
mutex m_lock;
// [...];
};
static global_ptr<foo> g_foo;
void threads()
{
for (;;)
{
local_ptr<foo> l_foo(g_foo);
if (! l_foo)
{
l_foo = new foo;
l_foo = g_foo.swap(l_foo);
}
l_foo->m_lock.lock();
l_foo->m_lock.unlock();
g_foo = NULL;
}
}
_________________________________________________________
`foo' objects are allowed to be dynamically created and destroyed on the
fly. Threads don't actually need to care about lifetime management because
the reference count handles all of that for them. Although, I have to say
that a library which has rules that basically demand using this type of
reference counting is pretty darn crappy.
== 5 of 5 ==
Date: Fri, Oct 30 2009 8:27 pm
From: frege
On Oct 28, 9:27 am, Noob <r...@127.0.0.1> wrote:
> [ Cross-posted to c.p.t and c.u.p ]
>
> Hello,
>
> I'm using a proprietary library (no source code) which requires the user
> to provide 4 mutex-related functions (create, delete, lock, unlock).
>
> AFAICT, if I were using a POSIX OS, I could make trivial wrappers around
>
> pthread_mutex_init
> pthread_mutex_destroy
> pthread_mutex_lock
> pthread_mutex_unlock
>
> But this library has specific requirements for the delete function:
>
> If delete is called on a locked mutex, the function must return an error
> code to signal the error to the function's caller.
>
> However, the documentation for pthread_mutex_destroy explicitly states:http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex...
>
> """
> It shall be safe to destroy an initialized mutex that is unlocked.
> Attempting to destroy a locked mutex results in undefined behavior.
> """
>
> This means that my delete function can't just call pthread_mutex_destroy
> because I would invoke UB if the mutex is locked, and I wouldn't be able
> to return the requested error code, right?
>
> So... Does this mean I have to keep track whether the mutex is locked?
> (It would appear so.)
>
> Or perhaps I could mess with the OS code? (shudder)
>
> I'd like to tell the library author that it is unreasonable to impose
> overhead on every lock and unlock operation just to catch an obvious (?)
> programming error on delete. What do you think?
>
> N.B. the library requires mutex with recursive semantic.
>
> Regards.
I basically agree with everyone else - the specs are stupid. But my 2
cents anyhow:
1. just don't implement it, but say you did. ie have delete never
return an error. The error would only ever been seen in broken code
anyhow.
or
2. ref count it:
class ByTheSpecMutex
{
boost::shared_ptr<RealMutex> pmutex;
public:
error_code delete()
{
if (pmutex->count() > 1)
return in_use_error;
...
}
};
Tony
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment