Related articles |
---|
Atomicity block alexili@ms.kyrnet.kg (2004-02-01) |
Re: Atomicity block lcargill@worldnet.att.net (Les Cargill) (2004-02-04) |
Re: Atomicity block thad@ionsky.com (Thad Smith) (2004-02-04) |
Re: Atomicity block tlh20@cus.cam.ac.uk (2004-02-04) |
Re: Atomicity block eventhelix@hotmail.com (2004-02-04) |
Re: Atomicity block nmm1@cus.cam.ac.uk (2004-02-08) |
Re: Atomicity block K.Hagan@thermoteknix.co.uk (Ken Hagan) (2004-02-12) |
Re: Atomicity block lcargill@worldnet.att.net (Les Cargill) (2004-02-13) |
From: | tlh20@cus.cam.ac.uk (T.L. Harris) |
Newsgroups: | comp.distributed,comp.programming,comp.compilers |
Date: | 4 Feb 2004 21:44:29 -0500 |
Organization: | University of Cambridge, England |
References: | 04-02-022 |
Keywords: | parallel |
Posted-Date: | 04 Feb 2004 21:44:29 EST |
Alexi <alexili@ms.kyrnet.kg> wrote:
>Many languages introduce structures/keywords for critical sections,
>monitors and other similar stuff that does synchronisation, mutual
>exclusion and etc. Is there anything similar for atomicity? I mean
>some monitor-like construction that would tell compiler to generate
>uninterraptable code that would have exclusive access to all addressed
>memory and may be other resources. All asynchronous events may be
>suspended until the end of such construct, that seems quite possible.
>And waht about exclusive memory access? This might require some
>support from OS/HW
Keir Fraser and I had a paper along these lines at OOPSLA 2003. We
used a software transactional memory (STM) as the basis of the
implementation. The paper focussed on making atomic updates to data
structures held in shared memory, but we've had some thoughts about
how to extend it to deal with some forms of I/O.
There are links to our work at
http://www.cl.cam.ac.uk/netos/lock-free
Tim
Return to the
comp.compilers page.
Search the
comp.compilers archives again.