llvm dev - Apr 2010 - [LLVMdev] Proposal for a new LLVM concurrency memory model

On 26 April 2010 10:49, Chandler Carruth <chandlerc at google.com>
wrote:
> Certainly for languages such as Java, they will make up a surprisingly
large
> chunk of the loads and stores, and instructions have much mor flexibility
in
> terms of syntax. On the flip side, it's a lot of plumbing IIRC, and
we'd
> really need to stick to the very minimal set of operations, supporting more
> obscure ones by pattern matching or intrinsics.
If you add it to the instructions, their syntax will be more complex
than they are today, and reading them could prove a challenge.

IMHO, we should keep it simple. I agree that multi-task is ubiquitous
nowadays but the detailed implementation might vary considerably from
language to language and making it explicit only helps, at least in
the beginning.

cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

On Mon, Apr 26, 2010 at 3:14 AM, Renato Golin <rengolin at systemcall.org>
wrote:
> On 26 April 2010 10:49, Chandler Carruth <chandlerc at google.com>
wrote:
>> Certainly for languages such as Java, they will make up a surprisingly
large
>> chunk of the loads and stores, and instructions have much mor
flexibility in
>> terms of syntax. On the flip side, it's a lot of plumbing IIRC, and
we'd
>> really need to stick to the very minimal set of operations, supporting
more
>> obscure ones by pattern matching or intrinsics.
>
> If you add it to the instructions, their syntax will be more complex
> than they are today, and reading them could prove a challenge.
To be clear, Chandler wasn't suggesting any change to the existing
load and store instructions. Instead, we were wondering if people like
the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe
atomic_exchange and atomic_add instructions.
> IMHO, we should keep it simple. I agree that multi-task is ubiquitous
> nowadays but the detailed implementation might vary considerably from
> language to language and making it explicit only helps, at least in
> the beginning.
>
> cheers,
> --renato

On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com>
wrote:
> To be clear, Chandler wasn't suggesting any change to the existing
> load and store instructions. Instead, we were wondering if people like
> the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe
> atomic_exchange and atomic_add instructions.
I see, in that case, I don't have any strong opinion. Maybe new
instructions would be simpler and cleaner...

I quite like the idea of having more expressive atomic operators, as
it'll be easier to map high-level synchronization concepts to IR.

cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm