search for: herlihy

...earch indicates this is extremely >>> uncommon." I don't understand this sentence, what do you mean? >> I'm not sure I can pinpoint the paper from which the statement is based, >> but I seem to recall something similar in the original LL-SC papers >> (Maurice Herlihy, DEC Western Research Labs?) It's a foundation for >> lock-free algorithms. > > Well, the statement says that often you have low contention. But that's > something you want, not necessarily something you will get, and depends on > the workload/algorithm. I'm missing...

...> before it is successful, research indicates this is extremely uncommon." > I don't understand this sentence, what do you mean? I'm not sure I can pinpoint the paper from which the statement is based, but I seem to recall something similar in the original LL-SC papers (Maurice Herlihy, DEC Western Research Labs?) It's a foundation for lock-free algorithms. > You probably don't need to require CAS (compare-and-set) to return the > previous value (I think some architectures don't), but just return a boolean > value (success/failure). compare and swap? &gt...

...ssful, research indicates this is extremely > > uncommon." I don't understand this sentence, what do you mean? > > I'm not sure I can pinpoint the paper from which the statement is based, > but I seem to recall something similar in the original LL-SC papers > (Maurice Herlihy, DEC Western Research Labs?) It's a foundation for > lock-free algorithms. Well, the statement says that often you have low contention. But that's something you want, not necessarily something you will get, and depends on the workload/algorithm. I'm missing the context. Is the act...

Hi, I'd like to see support for something like this. I have some comments, and I think there is existing work that you can reuse. TAS and CAS are _not_ theoretically equivalent. TAS is weaker because it can solve consensus in a nonblocking way only for 2 threads (it has consensus number 2), whereas CAS can solve consensus for any number of threads (infinite consensus number).

...this is extremely > > > uncommon." I don't understand this sentence, what do you mean? > > > > I'm not sure I can pinpoint the paper from which the statement is based, > > but I seem to recall something similar in the original LL-SC papers > > (Maurice Herlihy, DEC Western Research Labs?) It's a foundation for > > lock-free algorithms. > > Well, the statement says that often you have low contention. But that's > something you want, not necessarily something you will get, and depends on > the workload/algorithm. I'm missing t...

On Tuesday 10 July 2007 01:38, Scott Michel wrote: > As Chandler pointed out, LL/SC isn't blocking. It belongs to the > optimistic concurrency class of constructs. One of the earliest papers > (IIRC, the first paper) on LL/SC was: > > Herlihy, M. 1993. A methodology for implementing highly concurrent data > objects. ACM Trans. Program. Lang. Syst. 15, 5 (Nov. 1993), 745-770. > DOI= http://doi.acm.org/10.1145/161468.161469 > > LL/SC on the various RISC architectures are used for spin locks, but > they don't have to be...

Hello, After a fair amount of research and work, I have put together a concrete proposal for LLVM representations of atomic operations and synchronization constructs. These aim to provide the minimal functionality in the IR for representing the hardware constructs that threading libraries and parallel programming rely on. http://chandlerc.net/llvm_atomics.html While I am no expert on the