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]
> 
> 
> >
> >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. 
> 
> Except you don't know if a thread has been destroyed, the 
> handle closed,
> and then a new thread created with the same handle.  So, either you
> don't close the handles that you created during pthread creation and
> suffer a leak or you close them and suffer a race.

Huh? MS reuse Handle ID's for threads? Ouch ouch ouch. <thinking out
loud>Actually the problem here is that we want a handle leak, for the
time taken to hit the muto and find the thread dead, and we don't want
to be calling DuplicateHandle every time ownership changes. Now if we
put the thread handle in non-TLS storage, pointed to by TLS, then the OS
will not clean up the duplicated handle if the thread exits. So we WILL
know that the thread hasn't been destroyed and recreated. If we
encounter a dead thread, then by closing the handle when we recover the
muto, we will allow the thread handle to go away, thus fixing the leak.

So this does work. The overhead for it is 1 HANDLE per muto per thread.
</thinking>
 
> >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 :[.
> 
> That, I don't really care about.  It's the same issue as whether users
> want to use read() or ReadFile().  If they want to use 
> ReadFile in a cygwin program, that's fine but they can't expect
signals to interrupt it.

Ok. I don't know how pervasive muto was in cygwin, I had assumed that it
suddnly misbehaving would be fatal.

> >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.
> 
> Yeah, this is roughly what I think I proposed but I still think it is
> not feasible.
> 
> (Another thing that I would have liked to have is an 
> "OnThreadExit" function
> which could do this kind of cleanup automatically so you wouldn't have
> to worry about it.)

Yes, that would be wonderfull... pity MS wouldn't recognise mature API's
if the tripped over them.

> >> 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 :}.
> 
> Hmm?  I don't get it unless you are talking about using pthreads with
> more generic mutos everywhere.  I'm not going to use pthreads for the
> couple of cygwin threads that are currently in use.  There is 
> no reason to go through any extra overhead for these cases.

Sorry, I was suggesting the reverse, that the overhead should be so
small as to be insignificant and therefore incorporated into the main
muto class. But like you say, you don't use muto anywhere a thread can
crash and die on you, so you don't need to cover that case.

> But, like I said if we have an interesting replacement for a mutex I
> don't mind creating another muto-like object.  Maybe it could even
> be a new object derived from a muto.

Yes, I think this approach combined with memory mapping could actually
get quite fast cross-process mutex's. Certainly it can replace critical
sections on 95 (allowing the all important TryEnter capability).
 
> >>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?
> 
> Dunno.  I haven't given it much thought.  I kept trying to 
> come up with
> a method for allocating mutos dynamically and failing.  But I 
> don't exactly
> remember what the problem was.  It was easy enough to work around with
> static buffers but that's obvioulsy inappropriate for a 
> general purpose
> solution.


Ok.

Rob


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