first patch for process-shared semaphore

[David Xu]

John Baldwin wrote:
> On Wednesday 23 December 2009 10:12:19 pm Alexander Kabaev wrote:
>> On Thu, 24 Dec 2009 09:58:50 +0800
>> David Xu <davidxu at freebsd.org> wrote:
>>
>>> Alexander Kabaev wrote:
>>>> On Thu, 24 Dec 2009 09:22:34 +0800
>>>> David Xu <davidxu at freebsd.org> wrote:
>>>>> libthr does not require semaphore, it implements semaphore,
>>>>> it is easier than other ways to implement the process-shared.
>>>>>
>>>> Let me rephrase: I do not think semaphores belong in libthr. They
>>>> should be either in libc or in librt.
>>>>
>>>>
>>> OK, does others really implement semaphore in librt ?
>>> unfortunately, the librt already requires libpthread to implement
>>> SIGEV_THREAD.
>> I retract that. It appears that there is no consistency - Solaris put
>> these into libc, Linux into libpthread ans SUSv2 hints that these
>> belong with realtime functions. libthr is fine.
> 
> I vote for libc.  Single-threaded processes can use sem_open() and PSHARED 
> sem_init() as well.  Single-threaded processes can even use non-PSHARED 
> sem_init() by using fork() to create new "threads" that share the semaphore.
> 

OK, but will symbol version work in this way ? we already have
sem_init() in libthr, if we implement version 1.2 in libc, can linker
find newest version? I guess version 1.1 in libthr will be resolved
first by linker.

for example:
	cc -o threading_sem_test threading_sem_test.c -lthr

won't vesion 1.1 of sem_init in libthr be use firstly ? this is
obviously wrong.