With the aso*(), the assembler code looks fine. I used the code you've
posted, just added the & to arguments.
It translates to the __sync_* which implicitly include the memory barrier.
On 06/26/2014 02:06 PM, Glenn Fowler wrote:
Michal did you get the reordering problem with the aso*() code?
I checked my ubuntu build and the aso*() ops are macros that call the
__sync_* assembly directives as Adam notes below
if gcc optimization fiddles with __sync_* ordering that's a big problem
if the aso*() does fail to coax gcc to do what the code says then add
this line to the ksh93 Makefile and rebuild:
* :NOOPTIMIZE: io.c jobs.c xec.c
On Wed, Jun 25, 2014 at 8:27 AM, Michal Hlavinka <mhlav...@redhat.com
<mailto:mhlav...@redhat.com>> wrote:
volatile attribute is sufficient to enforce the inc/dec-rement to
happen and read/store the value from/to memory (not just register).
The reordering is bigger problem, (with just volatile) it did
something like this:
load memory to register
increment register
store register to memory
decrement memory
do the locked stuff (just assigning)
test whether last decrement was zero
do (or do not) the other tests from job_unlock and job_reap call
So it did both increment and decrement of job.in_critical
The volatile just means that all operations happen with memory and
not cached data (registers) and results are immediately written back
to memory.
Also all expressions using volatile variables will be executed in
specified order.
foo(int a) {
volatile int x=1 ,y=2;
int z=3;
z += a;
x = 3*x + a;
y = 2*y + a;
x = x + a;
y = y + a;
just says that both x = ... and y = ... will be executed as they are
written and stored to memory immediately after every assignment, but
both y = operations can be executed before z += and x =
there is no guaranteed order with respect to other volatile
variables if they are not using other volatile variable in assignment.
There is no control over ordering and AFAIK (looking for solution
half of yesterday) there is no standard way how to force the correct
order.
Only side effects of some hacks. The memory barrier hack being one.
On 06/25/2014 01:55 PM, Glenn Fowler wrote:
interesting that it was optimized out -- but it does seem to
follow the
letter of the standard
references to the volatile variable must access the actual
memory and
not be cached
in this case there is no reference because it was optimized out
so its easy
is there any standard way to force the increment to happen at any
optimization level?
I think job_unlock() needs 2 more memory barriers
along with volatile unsinged int in_critical or volatile struct
jobs job
try this portable code instead:
---
#define job_lock() asoincint(job.in_critical)
#define job_unlock() \
do { \
int _sig; \
if (asodecint(job.in_critical) == 1 && (_sig =
job.savesig)) \
{ \
if (asoincint(job.in_critical) == 0 &&
!vmbusy()) \
job_reap(_sig); \
asodecint(job.in_critical); \
} \
} while(0)
---
I believe this code with one less aso op is equivalent but I'm
not in a
spot to test it right now:
---
#define job_lock() asoincint(job.in_critical)
#define job_unlock() \
do { \
int _sig; \
if (asogetint(job.in_critical) == 1 && (_sig =
job.savesig) && !vmbusy()) \
job_reap(_sig); \
asodecint(job.in_critical); \
} while(0)
---
_______________________________________________
ast-developers mailing list
ast-developers@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers
