in a few weeks a new vmalloc implementation will be rolled out that should address all of the recent sbrk and thread related issues basically sbrk() will only be used by explicit request or by last resort
On Sat, 30 Jun 2012 09:40:26 +0200 Irek Szczesniak wrote: > On Thu, Jun 28, 2012 at 6:20 PM, Glenn Fowler <[email protected]> wrote: > > finally, the vmalloc sbrk() discipline already handles interlopers by always > > checking the current brk with its saved brk -- if different then vmalloc > > will only extend the brk beyond the current -- if all sbrk() consumers do > > this, > > *as they should if they were coded properly*, they can cooperate > So how should this work in a threaded application? Thread 1 with the > AST allocator checks brk and then uses sbrk() to expand it's horizon, > while thread 2 on a 2nd CPU (therefore operating in parallel with no > deterministic memory access order related to thread 1) does the same > in a private libc function. Or some other utility library you don't > control (libX11? libXCB?). > How do you prevent the race condition? > Irek _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
