This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add STATIC_GETENV macro.
- From: Torvald Riegel <triegel at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 14 Nov 2013 18:01:08 +0100
- Subject: Re: [PATCH] Add STATIC_GETENV macro.
- Authentication-results: sourceware.org; auth=none
- References: <20131109103822 dot GA9173 at domone> <1384356858 dot 3682 dot 13273 dot camel at triegel dot csb> <20131113213313 dot GB2747 at domone dot podge> <1384424038 dot 3682 dot 13505 dot camel at triegel dot csb> <20131114125253 dot GA24180 at domone dot podge> <1384444197 dot 3682 dot 13900 dot camel at triegel dot csb> <20131114164828 dot GA26024 at domone dot podge>
On Thu, 2013-11-14 at 17:48 +0100, OndÅej BÃlka wrote:
> On Thu, Nov 14, 2013 at 04:49:57PM +0100, Torvald Riegel wrote:
> > On Thu, 2013-11-14 at 13:52 +0100, OndÅej BÃlka wrote:
> > > Also when you are concerned about machines that do issue nonatomic reads
> > > then relaxed model is appropriate, acquire/consume could yield unacceptable
> > > performance overhead.
> >
> > Which relaxed model? Do you mean relaxed memory order? Atomicity is
> > orthogonal to ordering constraints enforced by particular memory orders.
> > Also, acquire/consume don't need any HW instructions on x86, sparc, and
> > the like (they still constrain compiler optzns, of course). Consume
> > should be very little overhead on Power, and even acquire shouldn't be
> > too much on Power and ARM.
> >
> All that is needed is that value returned has is from set initial/value
> returned by getenv.
No. You also need to ensure (or show that it holds in any case) that
whatever getenv() did on one Thread1 is also observed by Thread2 if
Thread2 read the value written by Thread1.
> It does not matter which one is read as long as this is from this set,
> so you do not need synchronization.
You do need atomic access to make that happen properly (ie, so that it's
guaranteed by what the language). Atomic accesses are synchronization.
You need to consider happens-before for the condition above, but whether
you need to do that with additional synchronization beyond atomic
accesses depends on the problem.
> In fact if one changed that variable to thread local without changing
> semantics.
If you made this thread-local, it would work because it avoids the
synchronization problems you have :)