svn commit: r214915 - user/davidxu/libthr/lib/libthr/thread

[David Xu]

David Xu wrote:
>>  
> I don't like the glibc's idea that reading or writing the mutex after 
> unlocked it,
> why do you think the memory is still valid and being used for the mutex
> after you unlocked it?
>
> There is a use-case that glibc will mysteriously fail:
> Thread  A at userland unlocked the mutex, then another thread B at
> userland locked it, and thread B reuses the memory area for other 
> purpose,
> before thread A enters kernel, thread B used it for memory-mapped file 
> buffer,
> than write some data into the buffer which will be saved into disk file
> by kernel, but before A runs, the memory happens to contains thread A's
> thread id, then the thread A enters kernel, and thinks the userland
> still hasn't unlocked the mutex, and it tries to write some data into 
> mutex,
> it thinks it unlocked it, but the memory is no longer for mutex now, 
> it just
> simply corrupted the data thread B saved. This implementation is racy and
> dangerous.
>
> I also know that they have link-entry embedded in mutex,
> if the mutex is being shared by multiple processes,then I can write a
> specific value into the link entry and corrupt the owner's link list,
> even worse, I can write a specific address into the link entry, when
> the owner unlocks it and unlinks it from its list, he will be happy to
> write to any address I specified,  this may be a security problem
> or causes very difficult debugging problem if the mutex memory
> is corrupted.
>
> I think if you want robust mutex, //for whatever you do, there is a 
> price,
> the robust mutex is expensive but reliable. Until you can prove that
> the glibc's write-mutex-memory-after-unlock is  not a problem,
> I would not follow their idea. Based on the research, I think
> Solaris must have a reason to not do it in this way, I would not laugh
> at them that their robust mutex is slow.
>
>
>
>
I also remembered Solaris 's  condition varaible is automatically
robust if your mutex is robust mutex type, glibc can not provide
the feature, when a process crashed, the condition variable's internal
lock may be held by the dead thread, and the condition variable is
in not usable state. but Solar's condition variable will still be in
health state, if a thread found the the pthread_mutex_lock returned
EOWNERDEAD, it still can use condition variable without any
problem. Without robust condition variable, a robust mutex is less
useful.