This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The direction of malloc?

On Wed, 2013-12-18 at 13:11 +0100, OndÅej BÃlka wrote:
> On Wed, Dec 18, 2013 at 01:01:24AM +0100, Torvald Riegel wrote:
> > On Tue, 2013-12-17 at 20:08 +0100, OndÅej BÃlka wrote:
> > > On Tue, Dec 17, 2013 at 01:59:57PM +0100, Torvald Riegel wrote:
> > > > On Mon, 2013-12-16 at 22:23 +0100, OndÅej BÃlka wrote:
> > > > > Please explain how spinning could improve performance in single thread
> > > > > applications.
> > > > 
> > > > You spoke about lockless code, so obviously concurrent code.  My comment
> > > > was thus referring to concurrent code.  If you have a single-threaded
> > > > program, then you can avoid synchronization, obviously (ignoring
> > > > synchronization just for reentrancy...).
> > > >
> > > And we for malloc use a switch variable to avoid lock path and set it
> > > when pthread_create is called? For reentancy a ordinary variable suffices.
> > 
> > Depending on the algorithm, even for reentrancy you might need atomic
> > operations (eg, to keep under control what the compiler does with the
> > code, or using a CAS to avoid pending stores).
> For reordering barrier it suffices to use
> __asm__ __volatile__( "" : : :"memory");

You can use that to constrain what the compiler does, I agree.  But why
not use relaxed-memory-order atomic accesses right away, instead of
trying to build the same thing manually with the compiler reorder

> Could a pending write really happen, it is kernel responsibility to do
> serialization which includes waiting for pending stores?

I mean "pending" on a conceptual, synchronization-related level.  It
refers to a situation in which the thread is suspended (due to
reentrancy, or also in concurrent settings) right before issuing a
store.  Because there's no operation before the store, it will always
overwrite a change someone else might have done (eg, the signal
handler), and there's no way to recover from that.  Unless the userspace
code can constrain where it is interrupted, there's nothing the kernel
or the HW can do to avoid that.  To avoid the pending-store problem, you
use atomic read-modify-write ops or CAS.

For example, you need those even for reentrancy-safe recursive locks;
you can't just do
  if (lock.owner == NULL) { lock.owner = me; }
because the store to lock.owner can be a pending store, which would
overwrite whoever actually acquired the lock.  You would need a CAS or

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]