thanks for catching the omitted '&' Update will be done tonight 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 <[email protected] > <mailto:[email protected]>> 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 [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
