[ELDK] glibc change for eldk 3.1.1

[Levend Sayar]

Hi,Detlev,

I checked the code piece. But there are to many defines due to too many mutex implementation it supports.
So it is not easy to follow. And in fact I did now want dig into code right now.

I did not hear something like inter process mutex like you. I don't believe there is something like that.
It must have been system wise accesible. I mean it must have somehing like a key (like semaphores, message queues for example)
pthread_mutex_* fucntions dont have this kind of interface.

I am really surprised eldk has libdb in it. Thank you very much for this warning. I am more surprised
that I did not looked at eldk before building my own. I am using many libraries. And my first step is to check eldk until today.
Anyway I will try with eldk based libdb and say the result ...

_lvnd_
 (^_^)


----- Original Message ----- 
From: "Detlev Zundel" <dzu at denx.de>
To: "Levend Sayar" <levend.sayar at karel.com.tr>
Cc: "Wolfgang Denk" <wd at denx.de>; <eldk at lists.denx.de>
Sent: Friday, March 26, 2010 3:54 PM
Subject: Re: [ELDK] glibc change for eldk 3.1.1


> Hi Levend,
> 
>> >>
>>> Ok, I'm getting lost here.  Threads are per definition defined on a
>>> process basis.  pthread_mutex is also a construction which I fail to see
>>> how to share it between processes.  Can you show me exactly what you
>>> want to do here?
>>
>> I aggree with you. AFAIK, mutexes are in fact intra process
>> primitives. But I dont understand why BerkeleyDB says these log lines
>> although
>> we have "pthread_mutex_init" function in our ELDK 3.1.1 toolchain.
>>
>> bdb(dc=karelarge,dc=com): unable to initialize mutex: Function not implemented
>> bdb(dc=karelarge,dc=com): PANIC: Function not implemented
>> bdb(dc=karelarge,dc=com): unable to join the environment
> 
> The first step here is to understand the problem.  I.e. find the source
> code responsible for this message and find out why the code produces
> this message.
> 
>> ------------------------------------------------------------------------------------------------------
>>
>>> Well interprocess synchronization is _per definition_ outside of threads
>>> as the latter are defined on a process basis.  For interprocess
>>> communication we have other primitives like SysV IPC, shared memory,
>>> etc.
>>
>> Exactly, semaphores for example
> 
> Ok, so slowly we are establishing a common base, good.
> 
>>>Can you show me such a wording?  This would be news to me.
>>
>> BerkeleyDB source code has a comment like this :
>>
>> "Currently we support one kind of mutex that is intra-process only,
>> POSIX 1003.1 pthreads, because a variety of systems don't support
>> the full pthreads API, and our only alternative is test-and-set."
>>
>> So I thought there is something in the standart like inter process mutex.
> 
> Weird.  Again I looked at the mag page of "pthread_mutex_init" and I do
> not see how one could use this to get to a mutex from another process.
> The _only_ way I can think of is to initialize a mutex and then do a
> fork() afterwards.  This way one would get multiple processes sharing
> the address space.  However one fork documentation[1] says this:
> 
>  When a programmer is writing a multi-threaded program, the first
>  described use of fork(), creating new threads in the same program, is
>  provided by the pthread_create() function. The fork() function is thus
>  used only to run new programs, and the effects of calling functions
>  that require certain resources between the call to fork() and the call
>  to an exec function are undefined.
> 
> So I doubt that this is legal use of pthread_mutexes.
> 
>>> I do not understand what you are doing here, sorry.
>>
>> I want to show you the alternatives for mutex implementation that
>> BerkeleyDB can use. Maybe someone will say "You have to choose this
>> one"
> 
> Ok, now that I reread this, I'm kind of surprised to find that ELDK
> 3.1.1 contains BerkeleyDB in version 4.0.14.  Did you try using that
> instead of building your own?
> 
> Cheers
>  Detlev
> 
> -- 
> Man gelangt nicht dazu, gluecklich zu sein, aber man macht Feststellungen
> ueber die Gruende, die uns daran hindern es zu sein.
>                                                -- Marcel Proust
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de