作者s4300026 (s4300026)
看板C_Sharp
标题[问题] 怎知 "方法(函式)" 执行者是谁?
时间Wed Sep 12 15:20:44 2018
C# 的各位先进好
小弟最近在使用backgroundworker做背景执行
假设主执行序执行Form
我想知道以下认知是否正确，或是可以有什麽方法可以知道是谁在做事情?
1. 主执行序的视窗类别的子类别直接执行某方法 是由 主执行序执行该方法
2. 主执行序的视窗类别的子类别的某方法 做成委派变数 给背景执行序执行
是由 主执行序执行该方法
delegate void MyMethod (void);
MyMethod method = subClassMethod;
void Scanner_DoWork(object sender, DoWorkEventArgs e)
{
method();
}
3. 承2.，但是给背景执行序委派 是由 主执行序执行 委派方法
void Scanner_DoWork(object sender, DoWorkEventArgs e)
{
method.Invoke();
}
------------
然後我还想知道 2.3 的差异性...
使用情境，我现在有个 RS232 传输装置
当我送出讯息给对方後，对方会回传给我对应的资料
目前的情况是我有两种状况都要传讯息：
1. 常态性背景扫描
2. 我的特殊要求
我在想，如果传输方法都是同一个执行序在执行
那我就不用费心去把方法锁住
System.Threading.AutoResetEvent unLocker;
但如果执行者是不同执行序
我就要考虑 RS232 当下有没有在执行 write的方法
不然我是否会遗失讯息
PS：目前我发现常常我的要求被 "忽视"，我在想到底是哪个环节出问题...
感谢大家聆听~~~
谢谢大家~
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 60.250.235.221
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_Sharp/M.1536736847.A.DE1.html
※ 编辑: s4300026 (60.250.235.221), 09/12/2018 15:22:37
1F：推 Litfal: DoWork事件是由非视窗执行绪触发执行 09/12 15:30
2F：→ Litfal: ProgressChanged 是由视窗执行绪执行 09/12 15:31
3F：→ Litfal: 要用 backgroundworker，遵守这个原则会比较清楚 09/12 15:31
4F：→ Litfal: 2、3是一样的 09/12 15:32
5F：→ Litfal: 在DoWork里面写个无限回圈去捞资料，拿到想显示的资料後， 09/12 15:35
6F：→ Litfal: 用 ReportProgress() 去触发 ProgressChanged，在事件里面 09/12 15:35
7F：→ Litfal: 再去调整UI 09/12 15:35
感谢您的热心回覆~~~
话说你的回答让我想起之前一直也想问的问题
事件管理者(event Eventhandler) 挂勾 事件响应方法
comPort.DataReceived += ComPort_DataReceived;
当事件发生(raise)後，事件响应方法是哪个执行序在执行的?
raise的执行序要做事，还是监听的执行序要做事
(就名词而言好像监听的执行序要做事比较合理... 是吗?)
离题了...
话说我之前没想过用ProgressChanged，是因为我觉得用不到
我的理由是
因为 comPort.DataReceived += ComPort_DataReceived; 挂上去後
我就已经可以直接收到资料了，然後就可以直接更新我的资料了。
那就不用ProgressChanged了阿... (也想不到怎麽用)
更直白地说，backgroundworker 只负责发送不负责接收阿...
※ 编辑: s4300026 (60.250.235.221), 09/12/2018 17:08:15
8F：推 DeathTemp: 试试看不要直接送出指令给RS232，而是先放在一个Queue 09/12 23:01
9F：→ DeathTemp: 里面，等到收完上个指令的回覆或者你定义的timeout後 09/12 23:02
10F：→ DeathTemp: 再送出下一笔指令，如果这样收资料就正常的话，那就是 09/12 23:02
11F：→ DeathTemp: 证实你的怀疑没错了 09/12 23:03
12F：推 Litfal: SerialPort.DataReceived 是从ThreadPool抓一个闲置的执行 09/13 12:21
13F：→ Litfal: 绪来raise，跟你注册的执行绪无关 09/13 12:22
14F：→ s4300026: 不是，我想表达的意思是目前写法是送收分离的 09/14 18:02
15F：→ s4300026: 我现在正在改成deathtemp的方法，虽然可能可以解决问题 09/14 18:06
16F：→ s4300026: ，但是我还是不明白要怎麽知道是哪个thread执行哪个方法 09/14 18:06
17F：→ s4300026: 啊！ 举例来说我会好奇litfal说的，为什麽backgroundwor 09/14 18:06
18F：→ s4300026: ker可以做到dowork事件是一个执行序，progresschange是 09/14 18:06
19F：→ s4300026: 另一个执行序 09/14 18:06
20F：推 Litfal: System.Threading.Thread.CurrentThread.ManagedThreadId 09/15 10:39
21F：→ Litfal: 元件的细节就是靠经验和看文件 09/15 10:41
22F：→ Litfal: BackgroundWorker设计上就是给WinForm做非同步用的，当然 09/15 10:42
23F：→ Litfal: 就会有耗时工作工作DoWork，由非视窗执行绪做，避免卡死UI 09/15 10:44
24F：→ Litfal: 以及ProgressChanged显示进度用，由视窗执行绪做，可以直 09/15 10:45
25F：→ Litfal: 接调整UI控制项。 09/15 10:45
26F：→ s4300026: 原来真的有阿！！太好了，这样就可以好好找问题了 09/15 15:32
27F：→ s4300026: 感谢litfal 09/15 15:32
28F：推 DeathTemp: 其实RS232 Device在上一笔指令还没处理完，又接到新指 09/16 00:31
29F：→ DeathTemp: 令的时候，直接忽视新指令是很常见的做法 09/16 00:32