PTT職涯區 / Stock (股票)

Re: [請益] 關於券商的下單限制已回收

看板Stock (股票)作者 (BIT一生)時間11年前 (2014/12/01 23:43), 11年前編輯推噓8(8推 0噓 31→)
留言39則, 7人參與, 最新討論串3/4 (看更多)
※ 引述《gto9992000 (小人物GINO)》之銘言： : 理論上再券商那就會被程式擋下，而我今天卻發生一樣的錯單， : 大家都知道很多金的那家是圈存制，通常你多下單都會被擋掉， : 平常我自己下單算是蠻快速，因此我沒看到成交單都會連續在下， : 因為以往經驗錢不夠就會被擋下，因此這習慣也很久。 : 但今天因為我自己看沒有成交單，馬上以為是價格沒觸及， : 馬上又再把價錢拉高再補單，結果兩筆都成交， : 但是我戶頭的錢卻沒有這麼多， 這很明顯是軟體的圈存機制存在有 race condition（電腦名詞，翻譯 也不會變比較好懂）你把它想成大家去搶廁所，正常情況是一間廁只有一個人進去， 檢查措施是門沒鎖，裏面沒人，就進去然後上鎖，結果在極度巧合情況下，幾乎同 時有兩人執行相同動作，導致一起進了同一間。這是軟體漏洞，理論上可以 完全避免，但有可能為了執行效率，券商程式人員人為選擇放棄最嚴謹的檢查，最 嚴格的檢查必須使用臨界區間 (critical section) 機制，但這會大幅度加重伺服 器負荷。當然也有可能就是單純程式有錯，而剛好 race condition 是相當難測試 並找出的一種軟體錯誤，開發人員一直沒有搞定，但因為機率低，所以就一直擺著。 很可能因為今天早盤是快市，而且你的下單間隔又短，所以發生了異外狀況（ 兩人擠進同一間廁所），解決方法是 1.券商改軟體（不太可能），2.不要在快市時 連續下單 3.連續單間隔加大，最好是前單回應確實出現再下下一單。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.232.188.103 ※ 文章網址: http://www.ptt.cc/bbs/Stock/M.1417448613.A.9D5.html ※ 編輯: bitlife (118.232.188.103), 12/01/2014 23:47:12
推
12/01 23:50, , 1F
專業，大致上了解
12/01 23:50, 1F
推
12/02 00:15, , 2F
現在是在上OS嗎？
12/02 00:15, 2F
推
12/02 00:18, , 3F
清新！專業！
12/02 00:18, 3F
推
12/02 01:02, , 4F
難怪我常要補錢...XD
12/02 01:02, 4F
推
12/02 02:31, , 5F
這邊有點在掉書袋 人點單子是序列式的邏輯
12/02 02:31, 5F
→
12/02 02:32, , 6F
除非有多重觸發條件不然不會race condition
12/02 02:32, 6F
→
12/02 02:32, , 7F
看來OS那本只有讀目錄?
12/02 02:32, 7F
→
12/02 06:33, , 8F
樓上,讀書不要只讀一半,先把你自己的「除非」想一想
12/02 06:33, 8F
→
12/02 06:34, , 9F
另外,我說過,有一種可能是為了效率,根本不做最嚴謹
12/02 06:34, 9F
→
12/02 06:35, , 10F
檢查。最後,原po的對帳單直接告訴你事情就是發生了
12/02 06:35, 10F
→
12/02 06:36, , 11F
我出社會第一份工作,就天天在弄VAX/VMS,SunOS,PC上
12/02 06:36, 11F
→
12/02 06:37, , 12F
的IPC,好幾年天天都在弄這個問題
12/02 06:37, 12F
→
12/02 06:38, , 13F
關於掉書袋這點我也不同意,我已經盡力想了一個廁所,
12/02 06:38, 13F
→
12/02 06:39, , 14F
的例子讓原po容易懂,你去找本書有廁所例子的再來說
12/02 06:39, 14F
→
12/02 06:39, , 15F
我掉書袋
12/02 06:39, 15F
推
12/02 12:38, , 16F
若單一事件觸發還能搞到race condition也是很奇怪
12/02 12:38, 16F
→
12/02 12:39, , 17F
那就是一個廁所 有多個門多人同時上
12/02 12:39, 17F
→
12/02 12:40, , 18F
這情境會發生在人工下電子單嗎?
12/02 12:40, 18F
→
12/02 12:44, , 19F
所以會發生這問題根本就程式架構很神奇
12/02 12:44, 19F
→
12/02 12:45, , 20F
或根本驗額度部分部分有邏輯或架構漏洞
12/02 12:45, 20F
→
12/02 12:50, , 21F
底下那篇有略加解釋,不過各家設計外人無法瞭解,合理
12/02 12:50, 21F
→
12/02 12:51, , 22F
推測是中台判斷額度是用銀行餘額扣除已成交回報的圈
12/02 12:51, 22F
→
12/02 12:51, , 23F
存額度,當中台有多台機器,平常沒問題,因為回報極快,
12/02 12:51, 23F
→
12/02 12:52, , 24F
使用者也不是超人,人工不可能幾ms內下２單(會用圈存
12/02 12:52, 24F
→
12/02 12:52, , 25F
制券商的人大概也不會用程式下單買賣股票),所以沒事
12/02 12:52, 25F
→
12/02 12:53, , 26F
遇到快市,前一張單尚未成交回報(快市造成lag),後一
12/02 12:53, 26F
→
12/02 12:53, , 27F
單用此邏輯判斷就會得到還有餘額可用. 以上只是舉例
12/02 12:53, 27F
→
12/02 12:54, , 28F
,不代表券商一定是這樣做. 如果是你說的有bug,原原
12/02 12:54, 28F
→
12/02 12:54, , 29F
po用這麼久早該遇到一次了
12/02 12:54, 29F
→
12/02 13:01, , 30F
忘了講,架構漏洞若屬於負載低一直沒事,負載高就偶爾
12/02 13:01, 30F
→
12/02 13:02, , 31F
出事,bug又一直抓不到,屬於race condition的可能性
12/02 13:02, 31F
→
12/02 13:02, , 32F
就非常高
12/02 13:02, 32F
→
12/02 13:04, , 33F
另外我上述舉的例子,是屬於人為選擇,不是bug,會有這
12/02 13:04, 33F
→
12/02 13:04, , 34F
種狀況是設計者事前就清楚知道的
12/02 13:04, 34F
推
12/02 15:06, , 35F
推樓上 最新回文內容看來是自己平台有問題
12/02 15:06, 35F
→
12/02 15:07, , 36F
我會覺得不適用race condition是人的操作很難達到
12/02 15:07, 36F
→
12/02 15:07, , 37F
同時競爭的情形 而不像邏輯電路常有時序差而發生
12/02 15:07, 37F
推
12/02 15:15, , 38F
我理解的race condition跟你的例子不太一樣說...
12/02 15:15, 38F
→
12/02 16:03, , 39F
t大可以說一下哪裏不一樣
12/02 16:03, 39F
‣ 更多 bitlife 的文章
文章代碼(AID): #1KV8obdL (Stock)
Stock 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 bitlife 的文章
文章代碼(AID): #1KV8obdL (Stock)