由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 除了Python和Rust,所有语言处理全局变量都错了
进入Programming版参与讨论
1 (共1页)
m*****n
发帖数: 3575
1
全局变量是什么?
全局变量是用来在不同线程之间共享状态的变量,
常用的有真伪型、整数型、字符串型以及索引型。
现在问题来了,同时对某个全局变量发生既读又写会怎样?
绝大部分的语言编译好的程序会崩溃。
虽然同时发生既读又写的概率很低,但逻辑上不是等于没有。
这也就是很多应用程序(包括谷歌浏览器和Word)莫名其妙闪退的根源。
解决办法是加锁,即对所有的全局变量的读写操作都加锁,保证对此变量操作的同时唯
一性。
Python被人诟病的一个原因是全局变量锁,即无论表面上有多少个线程,实际任何时间
上运行的只有一个线程,这就保证了不发生此种冲突。
Rust的精髓在于变量拥有理论,即事实上对每一个变量,无论全局与否,都强制分配了
锁。
反观其它语言,对于全局变量的编程表面上是自由的,其实是给开发者留了很多犯错空
间。
f*****4
发帖数: 1
2
只能运行一个线程,本身就是问题吧

【在 m*****n 的大作中提到】
: 全局变量是什么?
: 全局变量是用来在不同线程之间共享状态的变量,
: 常用的有真伪型、整数型、字符串型以及索引型。
: 现在问题来了,同时对某个全局变量发生既读又写会怎样?
: 绝大部分的语言编译好的程序会崩溃。
: 虽然同时发生既读又写的概率很低,但逻辑上不是等于没有。
: 这也就是很多应用程序(包括谷歌浏览器和Word)莫名其妙闪退的根源。
: 解决办法是加锁,即对所有的全局变量的读写操作都加锁,保证对此变量操作的同时唯
: 一性。
: Python被人诟病的一个原因是全局变量锁,即无论表面上有多少个线程,实际任何时间

m*****n
发帖数: 3575
3

你可以说它低级,但是它不犯错。
反之,高级的留下很多犯错余地,高级到哪里去了?

【在 f*****4 的大作中提到】
: 只能运行一个线程,本身就是问题吧
f*****4
发帖数: 1
4
可以并行,多线程,资源换速度
不犯错,什么都不干就可以不犯错,只是说这个标准怪怪的

【在 m*****n 的大作中提到】
:
: 你可以说它低级,但是它不犯错。
: 反之,高级的留下很多犯错余地,高级到哪里去了?

w*******g
发帖数: 9932
5
外行话啊。
全局变量本来就是垃圾设计
可以读写的全局变量更是垃圾中的战斗机
及时多线程同时可以读写全局变量也不等于会崩溃。
崩溃的原因往往是同时读写造成逻辑错误的结果
加锁是个解决办法,但是不一定是最优办法。死锁是一个问题,效率低下是另一个问题
有时候用transactional memory的乐观办法更好。

【在 m*****n 的大作中提到】
: 全局变量是什么?
: 全局变量是用来在不同线程之间共享状态的变量,
: 常用的有真伪型、整数型、字符串型以及索引型。
: 现在问题来了,同时对某个全局变量发生既读又写会怎样?
: 绝大部分的语言编译好的程序会崩溃。
: 虽然同时发生既读又写的概率很低,但逻辑上不是等于没有。
: 这也就是很多应用程序(包括谷歌浏览器和Word)莫名其妙闪退的根源。
: 解决办法是加锁,即对所有的全局变量的读写操作都加锁,保证对此变量操作的同时唯
: 一性。
: Python被人诟病的一个原因是全局变量锁,即无论表面上有多少个线程,实际任何时间

m*****n
发帖数: 3575
6

你这个观点和Go的channel观点很像,展开讲讲?

【在 w*******g 的大作中提到】
: 外行话啊。
: 全局变量本来就是垃圾设计
: 可以读写的全局变量更是垃圾中的战斗机
: 及时多线程同时可以读写全局变量也不等于会崩溃。
: 崩溃的原因往往是同时读写造成逻辑错误的结果
: 加锁是个解决办法,但是不一定是最优办法。死锁是一个问题,效率低下是另一个问题
: 有时候用transactional memory的乐观办法更好。

w*******g
发帖数: 9932
7
Go's channel is nothing new.
Concurrent ML 就是用message passing/mailboxes/channel, synchronous events
Haskell也可以用MVar, Channel built with MVar.
Scala's actor model also uses channel/message passing
Many methods of synchronization can be used but they are primarily grouped
as
(1) optimistic
(2) pessimistic
Locking based methods are pessimistic, which reduces concurrency
Transactional memory is optimistic but may require rollback.
In practice, locking is probably more predictable in terms of performance.
Parallel programming is more like an art. There is no magic bullet. No
fantastic language constructs that suddenly make everything simple and
efficient.
For well-understood problems, you can use simple constructs like map/reduce/
scatter etc. But for general algorithms, it will be epic disaster to use
global variables without some careful planning and proof of correctness.

【在 m*****n 的大作中提到】
:
: 你这个观点和Go的channel观点很像,展开讲讲?

1 (共1页)
进入Programming版参与讨论