我应该在代码中使用 thread.sleep 还是计时器？
我有以下代码，可以向订阅者发送短信。但是，一些短信被 SMSGateway 拒绝，因为我一次发送了太多短信。所以我想在这之间延迟一下。
像这样发送短信 -
foreach (DataRow row in dt.Rows)
{
//Gets Subscriber number
smsSender.destinationNum = Convert.ToInt64(row["callerID"]);
foreach (DataRow articleRow in dtArticle.Rows)
{
//Gets SMS content
smsSender.smsMessage = articleRow["news"].ToString();
//Then send out the SMS
smsSendder.sendSMS();
}
}
请提供建议，因为我没有线程和计时器的经验
I have the following code which send out SMS to the subscribers. However, some SMS were rejected from the SMSGateway because I'm sending too many SMS at one time. So I'm thinking to make a delay in between.
Sending out the SMS like this -
foreach (DataRow row in dt.Rows)
{
//Gets Subscriber number
smsSender.destinationNum = Convert.ToInt64(row["callerID"]);
foreach (DataRow articleRow in dtArticle.Rows)
{
//Gets SMS content
smsSender.smsMessage = articleRow["news"].ToString();
//Then send out the SMS
smsSendder.sendSMS();
}
}
Please advice because I have no experience with the threads and timers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这取决于应用程序的架构。
假设这是一个服务式应用程序，没有用户界面，只是从数据库中获取数据并将其发送到 SMS，那么 Thread.Sleep(...) 就可以了。
如果此应用程序有用户界面，并且您在 UI 线程上运行此 SMS 发送代码，则 Thread.Sleep(...) 将阻止您的 UI。实际上，在这种情况下，smsSender.sendSMS 可能已经阻止了您的 UI！
答案是重构，使该代码脱离 UI 线程。您只需使用计时器即可做到这一点，尽管您必须重构代码，以便将结果集缓存在本地对象中，并且计时器会迭代该集合一次发送一条短信。
无论哪种情况，我希望您在发送短信时不要锁定数据库。
It would depend on the architecture of the application.
Assuming this is a service-style app, with no user interface, that simply gets data out of the database and sends it to SMS, then Thread.Sleep(...) is fine.
If this app has a user interface, and you're running this SMS sending code on the UI thread, then Thread.Sleep(...) will block your UI. Actually, smsSender.sendSMS is probably already blocking your UI in this case!
Refactoring so that this code is off the UI thread is the answer. And you can do that simply by using a timer, although you will have to refactor the code so that the result set is cached in a local object and the timer iterates through the set sending one SMS out at a time.
In either case, I hope you don't have a lock on the database while you're sending SMSes.
您的问题被标记为 [asp.net]，因此我假设您有一个网页，当请求时，该网页将发送大量 SMS 消息（例如，当用户按下“提交”按钮或 HTML 表单中的类似内容时）。
在这种情况下，您可以让多个用户同时请求该网页。另外，您不想在为用户提供网页的线程中休眠。如果您这样做，那么在发送 SMS 消息时，用户等待网页响应将会出现延迟。
我建议这样：
Task.Factory。 StartNew）来处理数据库中的短信。该解决方案将消息发送卸载到后台任务，该后台任务的速度可以根据需要而减慢，并使用数据库引入持久性，以避免丢失消息，即使应用程序池被回收也是如此。
Your question is tagged [asp.net] so I assume that you have a webpage that when requested will send a number of SMS messages (e.g. when a user presses a "submit" button or something similar in a HTML form).
In that case you can have multiple users requesting the webpage simultaneously. Also, you don't want to sleep in the thread serving the web page to the user. If you do that then there will be a delay where the user waits for the web page to respond while the SMS messages are sent.
I would suggest something like this:
Task.Factory.StartNew) to process the SMS messages in the database.Thread.Sleeep).This solution offloads the sending of messages to a background task that can be as slow as required and introduces persistence using the database to avoid loosing messages even if say the application pool is recycled.
Thread.Sleep 更合适，因为它更好地模拟了等待方面。
Thread.Sleepis more appropriate, because it models better thewaitingaspect.Thread.Sleep() 应该是延迟调用 SMS 网关以防止服务器拒绝您的请求的不错选择。
我不认为 Thread.Sleep() 占用了 CPU。
Thread.Sleep() should be a good choice to delay calling to SMS gateway to prevent server reject your request.
I don't think it's Thread.Sleep() that's tying up the CPU.
Thread.Sleep 似乎设计不好。请参考http://blogs.msmvps.com/peterritchie/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-Designed-program/ 了解原因Thread.sleep 很糟糕。
计时器更准确，Thread.Sleep 只能保证至少等待您指定的时间（操作系统可能会使其休眠更长时间）。 。
Thread.Sleep seems bad design. Please refer http://blogs.msmvps.com/peterritchie/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program/ about why Thread.sleep is a bad.
Timer are more accurate, Thread.Sleep is only guaranteed to wait at LEAST as long as the amount of time you specify (the OS may put it to sleep for much longer). .