atomic

OpenGL 4.6 能取到的398个扩展 记录一下

自作多情 提交于 2020-08-06 08:55:00
0 : GL_AMD_multi_draw_indirect 1 : GL_AMD_seamless_cubemap_per_texture 2 : GL_AMD_vertex_shader_viewport_index 3 : GL_AMD_vertex_shader_layer 4 : GL_ARB_arrays_of_arrays 5 : GL_ARB_base_instance 6 : GL_ARB_bindless_texture 7 : GL_ARB_blend_func_extended 8 : GL_ARB_buffer_storage 9 : GL_ARB_clear_buffer_object 10 : GL_ARB_clear_texture 11 : GL_ARB_clip_control 12 : GL_ARB_color_buffer_float 13 : GL_ARB_compatibility 14 : GL_ARB_compressed_texture_pixel_storage 15 : GL_ARB_conservative_depth 16 : GL_ARB_compute_shader 17 : GL_ARB_compute_variable_group_size 18 : GL_ARB_conditional_render

Java并发编程volatile关键字

无人久伴 提交于 2020-08-05 07:49:32
volatile理解   Java语言是支持多线程的,为了解决线程并发的问题,在语言内部引入了 同步块 和volatile 关键字机制。volatile具有synchronized关键字的“可见性”,volatile变量对于每次使用,线程都能得到当前volatile变量的最新值,但是没有synchronized关键字的“并发正确性”,也就是说不保证线程执行的有序性。 特性 1、保证内存可见性   各个线程对主内存中共享变量的操作都是各个线程各自拷贝到自己的工作内存操作后再写回主内存中的。这就可能存在一个线程AAA修改了共享变量X的值还未写回主内存中时 ,另外一个线程BBB又对内存中的一个共享变量X进行操作,但此时A线程工作内存中的共享比那里X对线程B来说并不不可见.这种工作内存与主内存同步延迟现象就造成了可见性问题。Java提供了volatile来保证可见性,当一个变量被volatile修饰后,表示着线程本地内存无效,当一个线程修改共享变量后他会立即被更新到主内存中,其他线程读取共享变量时,会直接从主内存中读取。 2、不保证原子性   原子性在一个操作是不可中断的,要么全部执行成功要么全部执行失败。如a++,a+=1就不是原子性操作,volatile不能保证原子性。 3、禁止指令重排序 计算机在执行程序时,为了提高性能,编译器和处理器常常会做指令重排:   1.

Can an atomic release be “overwritten”?

最后都变了- 提交于 2020-08-05 07:31:31
问题 Say I have atomic<int> i; Thread A performs an atomic store/exchange with memory_order_release. Next, Thread B performs an atomic store with memory_order_release. Thread C performs an atomic fetch_add(0, memory_order_acquire); Does Thread C acquire dependencies from thread A and B or only thread B ? 回答1: Only B (I'm going to assume that by "next" you mean the modification order of the atomic is A -> B -> C so that by [atomics.order]p11 C 's RMW must read the value B wrote). See the note in

Can an atomic release be “overwritten”?

有些话、适合烂在心里 提交于 2020-08-05 07:31:10
问题 Say I have atomic<int> i; Thread A performs an atomic store/exchange with memory_order_release. Next, Thread B performs an atomic store with memory_order_release. Thread C performs an atomic fetch_add(0, memory_order_acquire); Does Thread C acquire dependencies from thread A and B or only thread B ? 回答1: Only B (I'm going to assume that by "next" you mean the modification order of the atomic is A -> B -> C so that by [atomics.order]p11 C 's RMW must read the value B wrote). See the note in

Is it safe to use the Structure dereference(->) operator on the result of std::atomic::load

梦想与她 提交于 2020-08-04 10:21:22
问题 Whilst trying to work with std atomic pointer, I ran into the following. Say I do this: std::atomic<std::string*> myString; // <do fancy stuff with the string... also on other threads> //A can I do this? myString.load()->size() //B can I do this? char myFifthChar = *(myString.load()->c_str() + 5); //C can I do this? char myCharArray[255]; strcpy(myCharArray, myString.load()->c_str()); I'm pretty sure C is illegal because myString might be deleted in the meantime. However I'm unsure about A

Is it safe to use the Structure dereference(->) operator on the result of std::atomic::load

别说谁变了你拦得住时间么 提交于 2020-08-04 10:20:37
问题 Whilst trying to work with std atomic pointer, I ran into the following. Say I do this: std::atomic<std::string*> myString; // <do fancy stuff with the string... also on other threads> //A can I do this? myString.load()->size() //B can I do this? char myFifthChar = *(myString.load()->c_str() + 5); //C can I do this? char myCharArray[255]; strcpy(myCharArray, myString.load()->c_str()); I'm pretty sure C is illegal because myString might be deleted in the meantime. However I'm unsure about A

Is it safe to use the Structure dereference(->) operator on the result of std::atomic::load

浪尽此生 提交于 2020-08-04 10:20:08
问题 Whilst trying to work with std atomic pointer, I ran into the following. Say I do this: std::atomic<std::string*> myString; // <do fancy stuff with the string... also on other threads> //A can I do this? myString.load()->size() //B can I do this? char myFifthChar = *(myString.load()->c_str() + 5); //C can I do this? char myCharArray[255]; strcpy(myCharArray, myString.load()->c_str()); I'm pretty sure C is illegal because myString might be deleted in the meantime. However I'm unsure about A

ebtables介绍【转】

▼魔方 西西 提交于 2020-07-29 11:14:25
(转自: https://blog.csdn.net/kv110/article/details/47919913 ) ebtables是与iptables类似的命令, 区别在于ebtables用于对以太网帧的过滤,iptables用于对ip数据包的过滤。 过滤流程见图 1. 命令格式 ebtables [-t table ] -[ACDI] chain rule specification [match extensions] [watcher extensions] target ebtables [-t table ] -P chain ACCEPT | DROP | RETURN ebtables [-t table ] -F [chain] ebtables [-t table ] -Z [chain] ebtables [-t table ] -L [-Z] [chain] [ [--Ln] | [--Lx] ] [--Lc] [--Lmac2] ebtables [-t table ] -N chain [-P ACCEPT| DROP| RETURN] ebtables [-t table ] -X [chain] ebtables [-t table ] -E old-chain-name new-chain-name ebtables [-t table ] -

芯片Timing sign-off Corner理解

被刻印的时光 ゝ 提交于 2020-07-28 17:26:13
参考博文:http://blog.sina.com.cn/s/blog_5ced60e80102y7pd.html 一颗健壮的IC芯片应该具有能屈能伸的品质,他需要适应于他所在应用范围内变化的温度、电压,他需要承受制造工艺的偏差,这就需要在设计实现过程中考虑这些变化的温度、电压和工艺偏差。 在STA星球,用 library PVT、RC corner跟OCV 来模拟这些不可控的随机因素。在每个工艺结点,通过大量的建模跟实测,针对每个具体的工艺,foundary厂都会提供一张推荐的timingsignoff表格, 建议需要signoff的corner及各个corner需要设置的ocv跟margin。这些corner能保证大部分芯片可以承受温度、电压跟工艺偏差,一个corner=libraryPVT+ RC corner + OCV,本文将关注于library PVT。 ------OCV(on-chip-variation)也是用来模拟cell的PVT及线的RC变化,与前面两个不同的是,前两者是芯片全局的PVT/RC Corner,OCV是芯片上内的局部偏差(包括process 、 voltage、temperature、network RC)。比如在STA分析setup时,并不是用最慢的library PVT来signoff就是最差情况,对于capture

《高性能MySql》摘抄

↘锁芯ラ 提交于 2020-07-28 12:23:42
1.3.事务 事务,有ACID的概念: atomic 原子性 consistency 一致性 isolation 隔离性 durability 持久性 原子性 一个事务必须被视为一个不可分割的最小工作单元,整个事务中的所有操作要么全部提交成功,要么全部失败回滚,对于一个事务来说,不可能只执行其中的一部分操作,这就是事务的原子性。 一致性 数据库总是从一个一致性的状态转换到另一个一致性的状态。因为事务最终没有提交,所以事务中所作的修改也不会保存到数据库中。 隔离性 通常来说,一个事务所作的修改在最终提交之前,对其它事务是不可见的。 持久性 一旦事务提交,则其所作的修改就会永久保存到数据库中。 这里的记忆方式是:事务是酸的。 Transaction is acid. 然后记忆 A代表 Atomic C 代表 consistency I 代表 isolation D代表 durability。然后对应ACID进行记忆,原子性—— 原子 ;一致性—— 能量守恒定律 ;隔离性—— 薛定谔猫 ;持久性—— 不可逆反应 。 1.3.1.隔离级别 隔离级别里说了很多,但核心的还是对于几种问题的处理。 脏读:事务中的修改,即使没有提交,对其它事务也都是可见的。(好像信纸上写字,写了一半,墨水还没干,另一个人就着急拿过来看,墨水在信纸上流淌,很脏) 幻读:当某个事务在读取某个范围内的记录时