T********i
发帖数: 2416 | 1 这人给他一根杆子就能顺着爬上去。
xadd和compexch到现在还搞不懂。
极品呀。 |
|
n*****t
发帖数: 22014 | 2 一个车次没问题了吧？
那你把 2 个高频转车的设想成新的虚拟车次就行了，就好比某次车延线了 |
|
z****e
发帖数: 54598 | 3 老魏，我说的是一种极端糟糕的情况，也就是理论上
当你dec前面的时候，达到最后了，因为量太大，最后怎么都是负数
所以无法出票的情况，这种可能性比较小，但是当N->无穷，这种情况是必然出现的
天朝人又多，我比较倾向于这种情况会出现
你可以用现实不可能存在来反驳
顺便说一下，1989那个排队的解法我不反对 |
|
|
g*****g
发帖数: 34805 | 5 你这么整，车次就要指数级上升，卖票出去之后，需要更新的计数器也指数级上升。 |
|
n*****t
发帖数: 22014 | 6 负数就洗洗睡了啊，前面正数的拿票走人，买不到联程的相当于退票 |
|
|
S*A
发帖数: 7142 | 8 可以啊，就是出现票被抢了，但是又没有出的情况
要多循环一两次。用户不需要知道。 |
|
z****e
发帖数: 54598 | 9 哈？那就会出现开一半，然后下车，等明天再上车的情况
农民工会起义的 |
|
n*****t
发帖数: 22014 | 10 不可能指数，本来转车就没几个，广大群众的基本策略是买到一张再说 |
|
z****e
发帖数: 54598 | 11 黄牛党会用挖比特币的机器跟你抢的
起一堆肉鸡，然后一声令下 |
|
S*A
发帖数: 7142 | 12 好吧，我宣布 27 楼的解法可以解决好虫提出来的问题。
不需要用户从新订票，多个循环就可以了。 |
|
b*******s
发帖数: 5216 | 13 我又跟我自己设计的那个内存数据结构搞了，我那个里面不统计票数，而是按位置锁的 |
|
n*****t
发帖数: 22014 | 14 啥情况啊，你整明白 interlock 原理没啊？100 张票， 1000 个人抢，100 个返回正
数、出票，跟后面 900 个卢瑟毛关系没有 |
|
|
|
z****e
发帖数: 54598 | 17 老魏不会是看上次我说了这个类，今天拿出来说的吧？
我当时说了三个int, Integer & AutomicInteger的例子
第一和第三不会有问题，第二就不能保证了 |
|
S*A
发帖数: 7142 | 18 要看冲突情况了。这个问题就跟 spinlock 要循环几次
是一样的啊。但肯定不会死锁。 |
|
n*****t
发帖数: 22014 | 19 你也得刚好在我的线程池里撞上，刚好 abc 先锁 |
|
z****e
发帖数: 54598 | 20 问题是后面900个不能保证时间上人家就在后面阿 |
|
z****e
发帖数: 54598 | 21 我的意思是这个数量可能远不是18倍，而是18000倍 |
|
g*****g
发帖数: 34805 | 22 你代表广大民工了？本来北京还能睡井底，到上海过年睡大街？ |
|
n*****t
发帖数: 22014 | 23 你也没法拿 timestamp 找我打官司不是？对铁老大来说，卖完了就拉倒，对卢瑟来说
活该倒霉，本来就有可能网络卡一下 |
|
g*****g
发帖数: 34805 | 24 你就简单来个sync block, 性能恐怕比你这个try and error还好。至少完成时间有保
障。 |
|
z****g
发帖数: 75 | 25 不用汇总排列。根据车次决定去哪个NIC->Thread就行了 |
|
n*****t
发帖数: 22014 | 26 上海大街比北京暖和，睡完大街你还能转中巴，再说了，转车的 pattern 有历史出票
记录，整几个虚拟车就是了 |
|
T********i
发帖数: 2416 | 27 你的问题在于不知道atomicint操作后还有返回值，以及返回值怎么用。
从你纠缠compexch来看，你根本就是迄今都不懂。
这个懂行的看得很清楚。眼里揉不得沙子的。 |
|
a***n
发帖数: 538 | 28 optimistic locking失败以后当然要rollback的。 |
|
i*****o
发帖数: 1714 | 29 不同车次的呢？
★ 发自iPhone App: ChineseWeb 8.6 |
|
S*A
发帖数: 7142 | 30 sync block 是要锁全部线程，每个时刻只有一个线程能有进展吗？
那个性能肯定不如这个。
当然网络 IO 的问题还是有待验证。 |
|
a***n
发帖数: 538 | 31 其实单线程也可以吧，都不需要用原子操作，票少的时候可能还快一点。 |
|
|
|
q*c
发帖数: 9453 | 34 是这样，我想叉了。
不过如果 bc 没了， 刷 abc 的就能把 ab 的全堵住，对吧？
这种异步交易问题多多。 |
|
g*****g
发帖数: 34805 | 35 一个北京－上海－兰州的票贩子，不停大量的发订单，占了所有订单的99%，另外1%是
广大人民的北京－上海单子。
偏偏上海－兰州已经卖完了。很有可能的结果就是北京－上海的票，一张都卖不出去。
大量无效订单不停进来，保证了北京－上海上不了0.
还什么10张，纯粹做了太监往回找脸。 |
|
i*****o
发帖数: 1714 | 36 前面有人说了，抢同一个车次的放到一个线程。
★ 发自iPhone App: ChineseWeb 8.6 |
|
b*******s
发帖数: 5216 | 37 在余票多的时候，不可能出现这个情况
只有剩余很少的票才会 |
|
|
z****e
发帖数: 54598 | 39 我们抽象一下
把thread变成一个具体的process
在不同的instance上
差距很大么？
反正都慢下来了 |
|
g*****g
发帖数: 34805 | 40 谁知道呢，比如还有北京－上海还有1000张票，上海－兰州没有了。票贩子先发了1000
个北京－上海－兰州的单子进来，群众才开始。票贩子不停补充消耗，你北京－上海就
永远上不了0.
1000张很少吗？ |
|
z****e
发帖数: 54598 | 41 这个时间一旦大到人能感觉出来
比如我今天上午9点一直刷，都没刷到
下午2点刷的都刷到了
那农民工就有砸了售票处的习惯
不患寡患不均哦 |
|
b*******s
发帖数: 5216 | 42 你看看我的解释，比如16个核绑了16个线程，实际上n也就是16，而不是1000
同一时刻不会变大
1000 |
|
q*c
发帖数: 9453 | 43 怎么会？人比票多10倍，从一开始票就很少。
刷 abc 的就是可以把 ab 的全堵住。bc 没了， 100万人狂刷 abc, 上 比特机， ab
虽然疯狂 rollback, 但就是一直是负数。
虽然 ab 一张票也没卖。
大家等退票，就能刷一天。 |
|
|
|
T********i
发帖数: 2416 | 46 上500万DOS attack，谁都别买了。
什么指标能对抗DOS? |
|
n*****t
发帖数: 22014 | 47 abc 的无法保证每次都抢在 ab 前面，所以每次都有漏网的，要不了几秒就彻底卖完了 |
|
q*c
发帖数: 9453 | 48 怎么先看？难道前面说的逐段 lockdecrement 不就是看吗？
你有别的两段式交易，就有别的死法。 |
|
|
|
