isolate changes, keep orignal musl sources clean.
Signed-off-by: NCaoruihong <crh.cao@huawei.com>
Change-Id: Id7f3a5109771f93d397e30febba36e09ddaf4f36

Description:add unsupport api print
Team: OTHERS
Feature or Bugfix:Feature
Binary Source:No
PrivateCode(Yes/No):No

Change-Id: If54639f876c6c6d546f36f65a83e3d4ae94a58f0
Reviewed-on: http://mgit-tm.rnd.huawei.com/10522043Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Ncaoruihong 00546070 <crh.cao@huawei.com>
Reviewed-by: Nshenwei 00579521 <denny.shenwei@huawei.com>

logically these belong to the intersection of the stdio and pthread
subsystems, and either place the declarations could go (stdio_impl.h
or pthread_impl.h) requires a forward declaration for one of the
argument types.

instead of using a waiters count, add a bit to the lock field
indicating that the lock may have waiters. threads which obtain the
lock after contending for it will perform a potentially-spurious wake
when they release the lock.

previously, stdio used spinlocks, which would be unacceptable if we
ever add support for thread priorities, and which yielded
pathologically bad performance if an application attempted to use
flockfile on a key file as a major/primary locking mechanism.

i had held off on making this change for fear that it would hurt
performance in the non-threaded case, but actually support for
recursive locking had already inflicted that cost. by having the
internal locking functions store a flag indicating whether they need
to perform unlocking, rather than using the actual recursive lock
counter, i was able to combine the conditionals at unlock time,
eliminating any additional cost, and also avoid a nasty corner case
where a huge number of calls to ftrylockfile could cause deadlock
later at the point of internal locking.

this commit also fixes some issues with usage of pthread_self
conflicting with __attribute__((const)) which resulted in crashes with
some compiler versions/optimizations, mainly in flockfile prior to
pthread_create.