并发编程网 - ifeve.com

大卫说：“服务的调用最终是通过函数实现的”。“但函数要绑定数据以确定并行的粒度”：皮特争辩道。早上大卫和皮特在花园里争论着，我们所开发的软件的结构究竟是面向对象还是面向函数？这个问题猛然听来好像非常矛盾。软件的结构似乎只能在面向对象和面向函数之间进行选择。但其实不然，面向对象和面向函数不过是我们在开发过程中的一种思考方式。当你从用户的角度来看开发的过程，就是面向对象的。因为用户最终操作的是一个很小的数据集合。这个集合可以抽象的叫做对象。当你换个角度从服务器这边去看时。服务器的数据被各种用户函数所操作。所有函数所拥有的数据的子集的合，构成了服务器的全部数据。并且每个函数的范围都不固定。可能操作很小的数据，也可能操作很大的数据。小到用户状态的更改。大到对几年的数据进行统计分析。哪么从服务器的角度来看就叫面向函数的编程。

原文地址 ，译文链接，译者：张军，校对：梁海舰

无锁(完全同步)

想象一下，一个无锁算法或数据结构有一个方法，这个方法所有执行过程都需要同步。假设在单线程模式下这个方法每次调用需要10ns，而每增加一个线程调用这个方法，将在同步状态(变量)上产生争用。
很显然，如果只有一个线程，每次调用该方法到返回平均时间都为10ns，我们称之为：每10ns完成的任务数；如果你增加更多的线程，他们将会增加其他线程执行完成的时间，这是因为同一时刻只有一个线程能获得锁；
记住，无锁(Lock-Free)保证一个线程可以执行，但没说是哪一个，并且在当前这个特定的例子中，每次只有一个线程可以执行(完成任务)，其他线程不得不从头开始：
阅读全文

原文链接 作者：Martin Thompson  译者：曹姚君 校对： 方腾飞

上周在由Heinz Kabutz通过JCrete 组织的开放空间会议(unconference)上，我参加一个新的java规范 JSR166 StampedLock的审查会议。StampedLock 是为了解决多个readers 并发访问共享状态时，系统出现的内存地址竞争问题。在设计上通过使用乐观的读操作，StampedLock 比ReentrantReadWriteLock 更加高效；

在会议期间，我突然意思到两点：

• 第一、我想是时候该去回顾java中锁的实现的现状。
• 第二、虽然StampedLock 看上去是JDK很好的补充，但是它视乎忽略了一个事实，即在多个reader的场景里，无锁的算法通常是更好的解决方案。

阅读全文

感谢trytocache投递本文。

前言

本文写给对ConcurrentLinkedQueue的实现和非阻塞同步算法的实现原理有一定了解，但缺少实践经验的朋友，文中包括了实战中的尝试、所走的弯路，经验和教训。

背景介绍

上个月，我被安排独自负责一个聊天系统的服务端，因为一些原因，我没使用现成的开源框架，网络那块直接使用AIO，收数据时，因为只会从channel里过来，所以不需要考虑同步问题；但是发送数据时，因为有聊天消息的转发，所以必需处理这个同步问题。AIO中，是处理完一个注册的操作后，再执行我们定义的方法，此时，如果还有数据需要写，则继续注册写操作，如果没有则不注册；提交数据时，如果当前没有注册写操作，则注册一个，否则仅提交（此时再注册则会报异常）。这样，需要同步的点就是：如何知道当前还有没有数据需要发送（因为其它线程也可以提交数据到此处），和如何知道此次提交时，有没有注册写操作。总之，要完成：有数据要发送时，必需有写操作被注册，并且只能注册一次；没有数据时，不能有写操作被注册。 阅读全文