`
aahyhaa
  • 浏览: 8247 次
  • 性别: Icon_minigender_1
  • 来自: 北京
最近访客 更多访客>>
社区版块
存档分类
最新评论

Atomicity and volatility

    博客分类:
  • Java
 
阅读更多

Atomicity applies to "simple operations" on primitive types except for longs and doubles. 

Reading and writing primitive variables other than long and double is guaranteed to go to 

and from memory as indivisible (atomic) operations. However, the JVM is allowed to 

perform reads and writes of 64- bit quantities (long and double variables) as two separate 

32-bit operations, raising the possibility that a context switch could happen in the middle of a 

read or write, and then different tasks could see incorrect results (this is sometimes called 

word tearing, because you might see the value after only part of it has been changed). 

However, you do get atomicity (for simple assignments and returns) if you use the volatile 

keyword when defining a long or double variable (note that volatile was not working 

properly before Java SE5). Different JVMs are free to provide stronger guarantees, but you 

should not rely on platform-specific features.  

Atomic operations are thus not interruptible by the threading mechanism. Expert 

programmers can take advantage of this to write lock-free code, which does not need to be 

synchronized. But even this is an oversimplification. Sometimes, even when it seems like an 

atomic operation should be safe, it may not be. Readers of this book will typically not be able 

to pass the aforementioned Goetz Test, and will thus not be qualified to try to replace 

synchronization with atomic operations. Trying to remove synchronization is usually a sign 

of premature optimization, and will cause you a lot of trouble, probably without gaining 

much, or anything.  

On multiprocessor systems (which are now appearing in the form of multicore processors—

multiple CPUs on a single chip), visibility rather than atomicity is much more of an issue 

than on single-processor systems. Changes made by one task, even if they’re atomic in the 

sense of not being interruptible, might not be visible to other tasks (the changes might be 

temporarily stored in a local processor cache, for example), so different tasks will have a 

different view of the application’s state. The synchronization mechanism, on the other hand, 

forces changes by one task on a multiprocessor system to be visible across the application. 

Without synchronization, it’s indeterminate when changes become visible.  

The volatile keyword also ensures visibility across the application. If you declare a field to be 

volatile, this means that as soon as a write occurs for that field, all reads will see the change. 

This is true even if local caches are involved—volatile fields are immediately written through 

to main memory, and reads occur from main memory.  

It’s important to understand that atomicity and volatility are distinct concepts. An atomic 

operation on a non-volatile field will not necessarily be flushed to main memory, and so 

another task that reads that field will not necessarily see the new value. If multiple tasks are 

accessing a field, that field should be volatile; otherwise, the field should only be accessed 

via synchronization. Synchronization also causes flushing to main memory, so if a field is 

completely guarded by synchronized methods or blocks, it is not necessary to make it 

volatile.  

Any writes that a task makes will be visible to that task, so you don’t need to make a field 

volatile if it is only seen within a task.  

volatile doesn’t work when the value of a field depends on its previous value (such as 

incrementing a counter), nor does it work on fields whose values are constrained by the 

values of other fields, such as the lower and upper bound of a Range class which must 

obey the constraint lower <= upper.

 

It’s typically only safe to use volatile instead of synchronized if the class has only one 

mutable field. Again, your first choice should be to use the synchronized keyword—that’s 

the safest approach, and trying to do anything else is risky.  

What qualifies as an atomic operation? Assignment and returning the value in a field will 

usually be atomic.

分享到:
评论

相关推荐

    Transaction Processing Concepts and Techniques 英文版

    事务处理的概念涉及事务的ACID特性,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)。原子性保证事务中的所有操作要么全部完成,要么全部不完成;一致性确保事务结束后...

    基于ssm+mysql的在线订花系统源码数据库论文.docx

    MySQL's robustness, scalability, and ACID (Atomicity, Consistency, Isolation, Durability) properties ensure data integrity and reliability. The online flower ordering system includes several key ...

    基于ssm+mysql的健身房众筹系统源码数据库论文.doc

    Its features, such as ACID (Atomicity, Consistency, Isolation, Durability) properties and SQL support, ensure data integrity and reliability. The MVC design pattern is crucial in separating concerns...

    atomicity:来自过去的经典 Mac OS。 原子锁、堆栈、受保护的堆栈、队列和受保护的队列

    在IT领域,原子性是多线程编程中的一个重要概念,特别是在并发控制中。经典Mac OS中的原子操作提供了保证数据一致性的方式,确保多个线程在访问共享资源时不会产生竞态条件。本文将深入探讨原子锁、堆栈、受保护的...

    《Expert SQL Server Transactions and Locking》源码

    - **事务特性(ACID)**:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。这些特性保证了事务的正确执行。 - **事务类型**:包括显式事务、隐式事务和自动提交事务,...

    Database and Transaction Processing Performance

    数据库性能测试手册(Database and Transaction Processing Performance Handbook)提到了JIM GRAY和Digital Equipment Corp共同编写的文献,该手册对于数据库系统和事务处理系统的性能度量提供了一个全面的参考。...

    Android SQLite 介紹

    ACID Compliant (Atomicity, Consistency, Isolation, Durability) Uses dynamic, weakly types data types and syntax Uses SQL query language – Implements most of SQL-92 SQL is mostly portable between ...

    Concurrency Control and Recovery in Database Systems全本.pdf

    5. **原子性(Atomicity)**和**持久性(Durability)**:这两个ACID特性是数据库恢复的基础,保证事务要么全部完成,要么完全不完成,且一旦事务完成,其结果将是永久的。 在分布式系统中,这些概念变得更加复杂,...

    微软内部资料-SQL性能优化3

    Atomicity A transaction either commits or aborts. If a transaction commits, all of its effects remain. If it aborts, all of its effects are undone. It is an “all or nothing” operation. Consistency ...

    jdbc api tutorial and reference

    - **ACID属性**:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)是事务的四个基本特性。 - **提交、回滚和保存点**:如何通过Connection对象控制事务的提交和回滚,以及...

    Linux操作系统课程指导:Ch5 System Calls.ppt

    Kernel enters a critical section where interrupts are disabled to ensure atomicity and consistency during the system call execution.Once the system call completes, control returns to user space ...

    Database Systems Practice Problems and Solutions

    事务处理是数据库管理中的一个核心概念,用于确保数据操作的原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability),通常称为ACID属性。事务是作为一个不可分割的工作单元执行的...

    数据库系统基础教程电子教案 Jeffrey D.Ullman and Jennifer Widom

    - ACID特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。 - 事务并发控制:解决多用户同时操作同一数据时可能引发的问题,如死锁和数据不一致。 7. 数据库恢复与...

    Transactions: Concurrency Control and Recovery

    - **原子性**(Atomicity):事务的所有操作要么都执行成功,要么都不执行。 - **一致性**(Consistency):事务的执行结果必须使数据库从一个一致性状态变到另一个一致性状态。 - **隔离性**(Isolation):事务...

Global site tag (gtag.js) - Google Analytics