Questions about Bionic

[fructose]

Hi

Is there a list of exactly where Bionic differs from Standard C /
Posix?

I read it doesn't support exceptions or wide chars, are there many
other differences?

If it doesn't support wide chars what is the situation regarding how
Unicode etc. is dealt with?


Is it possible to replace Bionic with your own version of libc at all?

[Dianne Hackborn]

On Fri, Feb 6, 2009 at 3:18 PM, fructose <david_p...@hotmail.com> wrote:

If it doesn't support wide chars what is the situation regarding how
Unicode etc. is dealt with?

ICU

And stick with UTF-8 and you'll be very happy.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[David Turner]

On Sat, Feb 7, 2009 at 12:18 AM, fructose <david_p...@hotmail.com> wrote:

Hi

Is there a list of exactly where Bionic differs from Standard C /
Posix?

I have written a document about that, but it still hasn't been dropped to the public open source tree
(due to practical reasons outside of my control). You'll find it attached to my answer.

(and yes, it's only the first version of the document)
 

I read it doesn't support exceptions or wide chars, are there many
other differences?

yep, plenty :-)
 

If it doesn't support wide chars what is the situation regarding how
Unicode etc. is dealt with?

The Android system uses ICU to deal with all internationalization needs.

For the record, ICU provides an interface that simply is *much* better than
anything coming from the corresponding standard C and C++ APIs.

And we decided there was no way we were going to support duplicate
functionality of this order of magnitude in our system.
  

Is it possible to replace Bionic with your own version of libc at all?

some people have tried that with more or less success, but I don't think this is
officially supported by the OHA at this point. Maybe some of them could comment
on this thread.

Regards

[vinay]

hi david,

thanks for sharing the bionic overview doc.
As mentioned in the document bionic is not supported multicore system. So on a system which has got two ARM A9 cores, how can we get best out of existing bionic lib. Are there any plans to support this multi-core support.

 

thanks,

-vinay

[David Turner]

yes, they are plans to support that. no ETA yet

[fructose]

Can Bionic be replaced with a standard, or your own, version of libc?

[David Turner]

It's probably do-able, but I don't know how much effort this represents.

[JayBird]

Hi David,

I read you overview document, and I have a question regarding C++
exceptions. If our C++ does not create any threads, is it safe to use
exceptions?

Regards,
Jay




On Feb 6, 9:43 pm, David Turner <di...@android.com> wrote:

>  OVERVIEW.TXT
> 19KViewDownload

[David Turner]

exceptions and threads are totally orthogonal concepts, so the answer is that not using any thread doesn't add any safety.
the real problem is that you won't be able to link your library/executable though

[vinay harugop]

hi david,
As mentioned in bionic overview document "Bionic does not provide or
use read/write memory barriers" for multi-core. what does it mean?
Could you please explain a bit more detail on this ?

if you can give some example it will great..

thanks,
-vinay

On Feb 7, 12:12 pm, David Turner <di...@android.com> wrote:
> yes, they are plans to support that. no ETA yet
>
>
>
> On Sat, Feb 7, 2009 at 8:07 AM, vinay <vinc...@gmail.com> wrote:
> > hi david,
> > thanks for sharing the bionic overview doc.
> > As mentioned in the document bionic is not supported multicore system. So
> > on a system which has got two ARM A9 cores, how can we get best out of
> > existing bionic lib. Are there any plans to support this multi-core support.
>
> > thanks,
> > -vinay
>
> > On Sat, Feb 7, 2009 at 9:13 AM, David Turner <di...@android.com> wrote:
>

> >> Regards- Hide quoted text -
>
> - Show quoted text -

[David Turner]

It means that proper synchronization/atomicity is not supported on certain SMP systems
(depending on how their memory bus / cache interconnect is designed).

The real issue is that read/write to/from main memory happen in a very non-deterministic way on modern systems,
which is much different than what is dictated by the source code.

• An agressive compiler will liberally reorder memory loads and stores in the generated source code if it can determine
  that this doesn't change the semantics of the program (this is why using the "restrict" keyword can have significant
  impacts on performance). All it can do is reorder instructions in the generated machine code, but you can somehow
  instruct it to avoid this reordering by using "volatile" variables and/or compiler-specific "barriers".
  

• After that, the CPU itself may also do some reordering (when converting the machine code into micro-ops or whatever)
  that are issued to the cache (the CPU never talks directly to main memory), very conservatively though.
  

• Then, the cache will speculately load cache lines from main memory, even before the CPU requests the corresponding
  data, and only write back the cache lines to main memory well after the CPU performed corresponding memory stores.
  

In a multi-core setup, each CPU has its own cache, which may perform speculative loads / delayed writes at different times.

Atomic operations, by definition, need to read/write values from/to main memory that is the only one shared by all CPUs.
Without some sort of cache coherency support, this cannot work well in SMP. Fortunately, multi-core architectures support this
through the use of specific hardware machine instructions to deal with this.

These are usually described as "read barrier" and "write barrier".

In a nutshell (though real implementation details are a lot weirder than that):

• a "read barrier" ensures that a loaded value comes from main memory, and not a speculated or populated cache line.
• a "write barrier" ensures that a writes goes directly to main memory.

Given today's architectures, they are significantly slower than the corresponding cached read or write.
The rules are, if you need to share data through main memory, you need to use a read barrier before reading the
data, and a write barrier to write it. Always couple a read barrier with a write barrier too.

These are also called "atomic acquire" and "atomic release" semantics in the litterature.

Note that a "cmpxchg" hardware instruction also usually corresponds to a "full barrier" (i.e. both read and write).

These special machine instructions only exist on CPU architectures that support multi-core (hence not ARMv5, I'm unsure
about ARMv6).

The point of the description message is that we need to add specific functions within the C library to perform
atomic_read() and atomic_write(), then modify our code to use it whenever appropriate.

On ARMv5, these functions would be simple loads/stores, and would not change the generated machine code at all.

Hope this makes it clear. Here are a few links to help you go further.

http://en.wikipedia.org/wiki/Memory_barrier
http://people.redhat.com/drepper/cpumemory.pdf