在不使用显式锁的方式下使用多线程

一个串被定义为序列的调用事件句柄(非并行调用),使用串允许在多线程环境中执行代码而不使用显示的互斥锁。

串可以是隐式的或者显式的,如下方的可替代方法所示:

仅在一个线程中调用io_service::run()意味着使用隐式的串执行所有的事件句柄,因为io_service确保了句柄只被run()内部调用。

当有一个只和一个连接关联的异步操作链时(比如半双工的协议HTTP),不可能并发的执行句柄,这是一个隐式的串。

显式的串调用是一个io_service::strand的实例,所有的事件句柄函数需要使用io_service::strand::wrap()包装,或者通过io_service::strand对象进行通告、发送。

如果是异步操作,比如async_read()或者async_read_until(),如果一个完成句柄通过一个strand,所有其他的中间句柄也都需要通过同一个串,这是为了保证在调用者和完成操作之间共享的对象的线程安全(在async_read() 的情况下是socket,调用者可以通过close来关闭操作),这是通过给所有指向同最终句柄关联的自定义句柄的中间对象嵌入hook函数来完成的。

struct my_handler

{

void operator()() { ... }

};

template<class F>

void asio_handler_invoke(F f, my_handler*)

{

// Do custom invocation here.

// Default implementation calls f();

}

io_service::strand::wrap() 创建了一个定义了 asio_handler_invoke 的新完成句柄,以便函数对象通过strand来执行。

串的英文为strand。

时间: 2024-10-13 14:51:48

在不使用显式锁的方式下使用多线程的相关文章

第13章 显式锁

性能是一个不断变化的指标,如果在昨天的测试基准中发现X比Y更快,那么在今天就可能已经过时了. 在激烈竞争的情况下,在非公平锁的性能高于公平锁的性能的一个原因是:在恢复一个被挂起的线程与该线程真正开始运行之间存在着严重的延迟.假设线程A持有一个锁,并且线程B请求这个锁.由于这个锁已被线程A持有,因此B将被挂起.当A释放锁时,B将被唤醒,因此会再次尝试获取锁.与此同时,如果C也请求这个锁,那么C很可能会在B被完全唤醒之前获得.使用以及释放这个锁.这样的情况是一种“双赢”的局面:B获得锁的时刻并没有推

显式锁(四)Lock的等待通知机制Condition

?? 任意一个Java对象,都拥有一组监视器方法(定义在根类Object上),主要包括:wait( ).wait(long timeout).notify().notifyAll()方法:这些方法与关键字synchronized结合使用,可以实现 隐式锁的等待/通知机制.而显示锁Lock也实现了等待/通知机制:Condition接口也提供了类似Object的监视器方法,与Lock配合使用可以实现 显式锁的等待/通知机制,但是两者在使用方式和功能特性有所差别.总得来说,Condition接口更加灵

并发编程—4显式锁 Lock

目录 4.显式锁 Lock 4.1 概念 内置锁 vs 显示锁 可重入锁 vs 不可重入锁 公平锁 vs 非公平锁 读锁 vs 写锁 4.2 ReentrantLock源码解读 4.显式锁 Lock 4.1 概念 内置锁 vs 显示锁 synchronize是java语言层面实现的锁,称为内置锁.使用方便代码简洁,而且在jdk新版本优化后,性能也得到了很大的提高.synchronize是一个可重入锁.而Lock是jdk提供开发者是用的一个显式锁.通过lock()和unlock()方法加锁和释放锁

java之AQS和显式锁

本次内容主要介绍AQS.AQS的设计及使用.ReentrantLock.ReentrantReadWriteLock以及手写一个可重入独占锁 1.什么是AQS? AQS,队列同步器AbstractQueuedSynchronizer的简写,JDK1.5引入的,是用来构建锁或者其他同步组件的基础框架,它使用了一个int成员变量表示同步状态,通过内置的FIFO队列来完成资源获取线程的排队工作.AQS的作者Doug Lea大师期望它能够成为实现大部分同步需求的基础. 2.AQS的设计及其作用 Abst

浅析SQL查询语句未显式指定排序方式,无法保证同样的查询每次排序结果都一致的原因

本文出处:http://www.cnblogs.com/wy123/p/6189100.html 标题有点拗口, 先抛出问题:一个查询没有明确指定排序方式,那么,第二次执行这个同样的查询的时候,查询结果会不会与第一次的查询结果排序方式完全一样? 答案是不确定的,两个完全一样的查询,结果也完全一样,两次(多次)查询结果的排序方式有可能一致,有可能不一致. 如果不一致,又是什么原因导致同样的查询默认排序方式不一致? 以下简单分析几种情况,说明为什么查询同样的查询会出现默认排序结果不一样的情况.当然对

JDK并发包温故知新系列(五)—— 显式锁与显式条件

显式锁-Lock与ReadWriteLockJDK针对Lock的主要实现是ReentrantLock,ReadWriteLock实现是ReentrantReadWriteLock.本文主要介绍ReentrantLock. ReentrantReadWriteLock两把锁共享一个等待队列,两把锁的状态都由一个原子变量表示,特有的获取锁和释放锁逻辑. ReentrantReadWriteLock的基本原理:读锁的获取,只要求写锁没有被线程持有就可以获取,检查等待队列,逐个唤醒等待读锁线程,遇到等待

Java并发编程系列-(4) 显式锁与AQS

4 显示锁和AQS 4.1 Lock接口 核心方法 Java在java.util.concurrent.locks包中提供了一系列的显示锁类,其中最基础的就是Lock接口,该接口提供了几个常见的锁相关的操作. public interface Lock { void lock(); void lockInterruptibly() throws InterruptedException; boolean tryLock(); boolean tryLock(long time, TimeUnit

java多线程9.使用显式锁

在协调共享对象的访问时可以使用的机制有synchronized和volatile.java 5.0新增了一种新的机制:ReentrankLock. ReentrankLock并不是一种替代内置加锁的方法,而是当内置加锁机制不适用时,作为一种可选择的高级功能.与无条件的锁获取模式相比,它具有更完善的错误恢复机制,而且它能够支持中断.Lock与ReentrantLock Lock提供了一种无条件的.可轮询的.定时的以及可中断的锁获取操作,所有加锁和解锁的方法都是显示地. 在Lock的实现中必须提供与

Java显式锁学习总结之二:使用AbstractQueuedSynchronizer构建同步组件

Jdk1.5中包含了并发大神Doug Lea写的并发工具包java.util.concurrent,这个工具包中包含了显示锁和其他的实用同步组件.Doug Lea在构建锁和组件的时候,大多是以队列同步器(AbstractQueuedSynchronizer)为基础的,因此AbstractQueuedSynchronizer可以看作是并发包的基础框架.因此掌握了AbstractQueuedSynchronizer的实现原理,也就掌握了大多数并发组件的实现原理. AbstractQueuedSync