diff options
| author | cinap_lenrek <cinap_lenrek@felloff.net> | 2014-06-05 21:54:32 +0200 |
|---|---|---|
| committer | cinap_lenrek <cinap_lenrek@felloff.net> | 2014-06-05 21:54:32 +0200 |
| commit | 91614f582fb1504ae3be2d57c079f24b60d71613 (patch) | |
| tree | 47382b0ee5f71cccc75f1e08f8ef7ff9e216765e /sys/src/9/port/allocb.c | |
| parent | 76db435e3cf86e0a6eb750d789bc15b64027a379 (diff) | |
kernel: dont use atomic increment for Proc.nlocks, maintain Lock.m for lock(), use uintptr intstead of long for pc values
change Proc.nlocks from Ref to int and just use normal increment and decrelemt
as done in erik quanstros 9atom.
It is not clear why we used atomic increment in the fist place as even if we
get preempted by interrupt and scheduled before we write back the incremented
value, it shouldnt be a problem and we'll just continue where we left off as
our process is the only one that can write to it.
Yoann Padioleau found that the Mach pointer Lock.m wasnt maintained
consistently for lock() vs canlock() and ilock(). Fixed.
Use uintptr instead of ulong for maxlockpc, maxilockpc and ilockpc debug variables.
Diffstat (limited to 'sys/src/9/port/allocb.c')
| -rw-r--r-- | sys/src/9/port/allocb.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/sys/src/9/port/allocb.c b/sys/src/9/port/allocb.c index 60d538325..3466840f2 100644 --- a/sys/src/9/port/allocb.c +++ b/sys/src/9/port/allocb.c @@ -65,7 +65,7 @@ allocb(int size) if(up == nil) panic("allocb without up: %#p", getcallerpc(&size)); while((b = _allocb(size)) == nil){ - if(up->nlocks.ref || m->ilockdepth || !islo()){ + if(up->nlocks || m->ilockdepth || !islo()){ xsummary(); mallocsummary(); panic("allocb: no memory for %d bytes", size); |