This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: muto object.


> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com]
> 
> 
> On Mon, Sep 17, 2001 at 12:22:55PM +1000, Robert Collins wrote:
> >Chris, 
> 
> >The logic it uses is:
> >if we fail to wait for the event,
> >protect ourselves with recover
> >check for the thread having died (should be fast - noop 
> basically) and
> >if it has aquire the muto anyway.
> 
> >There was also a typo in the destructor that could be causing memory
> >leaks within process.
> 
> Yeah, that was a stupid typo wasn't it?  I think it would 
> have caused a
> handle leak not a memory leak though, right?  Luckily, in the present
> situation, muto destructors are only called when the process exits (if
> then) so it hasn't been an issue.

Ah yes, Handle not memory.
 
> One thing that I considered doing is registering the current stack
> address and then testing to see if the aquirer's stack 
> address was still
> around after a timeout.  That obviously isn't foolproof, though.
> 
> If we wanted to generalize this then maybe pthread creation could use
> a DuplicateHandle to store a thread handle in thread local storage.
> Thread local storage should be pretty lightweight, too.  Then acquire
> could just use the same handle every time.

> Wait.  Nope.  Then you'd just have a handle leak or a handle race if
> you closed the handle in pthread_destroy (or whatever it is that gets
> rid of a pthread).

No, you'd be ok, because thread creation and destruction is not
serialised. And I don't believe it ever needs to be. You'll also note
that DuplicateHandle is only called when the ownership changes. 

However, unless we use pthreads internally (which should be fine) we
can't do the above because the pthread code is never hit. We also cannot
assume that the end user is always using our pthreads :[. So what we
need to do is have a static TLS id for the muto class, and the muto
constructor (using a interlock protected static var) creates the TLS id.
Then it, and every subsequent constructor stores the Dup'd handle (or a
pointer there to) there.
 
> Anyway, if you can do timings that verify that a muto + 
> DuplicateHandle
> is faster than a mutex then I don't have any problem with your using
> the algorithm in pthreads but I don't think I want to deal with the
> overhead in cygwin itself.

See above :}.
 
> One other issue is that I always had a problem with muto creation
> because if you use normal malloc/free operations they are 
> created prior to fork_child.  Then they are immediately overwritten by
fork/child.
> At least I think that is why I used static buffers.  I don't exactly
> remember anymore.

Ok, so we need static muto's everywhere? or can we add a muto to a
malloc'd class and that will be ok?

> One other reason that I used this structure rather than a 
> Win32 provided
> mechanism is that the signal handler has to be able to figure out if
> the thread that it is about to interrupt owns any locks and either
> break the lock or loop until the lock is released.
> 
> I don't know how this plays with a real multithreaded application that
> uses signals, though.  I suppose that the application would have to
> make sure that it dealt with these issues.  In the cygwin DLL I have
> more control so I can concentrate all of the muto wait detection in
> the cygwin signal handling code itself.
> 
> I really wish that Microsoft had given us an open a thread given the
> thread id function similar to OpenProcess.  I think I read somewhere
> that they actually did have a reason for not doing so but it 
> makes these
> kind of situations hard.

They did, it's 2k+ only :[. GetThreadHandle (Id) IIRC.

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]