タグ付けされた質問 「multithreading」

問題は、現在のスレッドがメインスレッドであることを表明する単体テストを記述することには意味があるのでしょうか。長所短所？ 最近、サービスのコールバックのために現在のスレッドをアサートする単体テストを見ました。いいアイデアだとは思いませんが、もっと統合テストだと思います。私の意見では、単体テストはメソッドを個別にアサートする必要があり、サービスの利用者の性質については知らないはずです。 たとえば、iOSでは、このサービスのコンシューマーは、デフォルトでメインスレッドでコードを実行するための制約を持つUIであることが意図されています。

8 architecture  unit-testing  object-oriented-design  multithreading  ios 

プロセスの存続期間中実行し続けるデーモンスレッドを生成するオブジェクトが必要です。議論のために、それは組み込みシステムのスレッドであり、いくつかの診断ポートでコマンドを受信して​​処理するのを待機しているとしましょう。しかし、それは本当に何でもあり得ます。主なアイデアは、長期間にわたって何かを見ているということです。一連のタスクを実行していません。 一般的なJavaの知恵によると、「インスタンス化しないThreadでくださいExecutorService。代わりに使用してください」です。（例えば、この答えを見てください）しかし、利点は何ですか？単一の長期実行スレッドを作成する手段としてスレッドプールを使用しても、意味がないようです。私がこれを書いた場合よりどのように良いでしょうか？ class Foobar { public Foobar() { this.threadFactory = Executors.defaultThreadFactory(); ... } public Foobar(ThreadFactory threadFactory) { this.threadFactory = threadFactory; ... } public void start() { fooThread = threadFactory.newThread(new Runnable() { ... }); fooThread.setDaemon(true); fooThread.start(); } ... } 注：この質問は私の質問に似ていますが、答えはスレッドプールの使用方法のみを示し、理由は述べていません。

8 java  design  multithreading 

データをクエリするスレッドと同じデータを更新するIOイベントを同期するときに、いくつかの同時実行バグが潜んでいると思われるJavaコードを継承しました。ThreadSafeと呼ばれる静的分析ツールを試しています。これは、さまざまな同時実行性の問題（つまり、非同期に呼び出されたメソッドから同期されていないフィールドにアクセスしたフィールドと、コレクションへのアクセスの一貫性のない同期）を実際に検出します。 単体テストを作成してデータの競合を確実に再現することがどれほど難しいかを発見した後、バグを確実に「再現」するためにThreadSafeに依存することが賢明かどうか疑問に思いましたか？私が求めているのは、バグをいつ修正したかを静的分析ツールに頼って教えても安全ですか？（もちろん、バグを修正するには、状況に応じてそれぞれを理解する必要があります）。

8 multithreading  debugging  static-analysis 

だから私はGoingNative 2012：誰もが質問できるインタラクティブパネルでこれらすべてのC ++マスターと共にYoutubeでこのビデオを見ました。 これは私が話していたビデオです：GoingNative 2012-1日目-インタラクティブパネル：ネイティブであることの重要性 そして時間0:24:00に誰かが非常に興味深い質問をしました： 私たちはしばらくの間、pthreadを使用したり、Windowsスレッドを使用したりして並行プログラミングを行ってきました。C++とCが並行プログラミングに追いついてうれしいですが、すでに5年または10年遅れているように思えます何年もの間、現在、これらの強力なマルチコアがすべてあり、これらのマルチコアのプログラミングはスレッドに基づくべきではなく、タスクベースである必要があり[...]、MicrosoftにはPPLライブラリなどがあり、これは完全にC ++標準には反映されていません。[...]私が恐れている唯一のことは、標準がスレッドにロックされ、タスクベースのプログラミングに移行するのが非常に困難になることです... 今、私はこれらの概念にかなり慣れていないので、少し混乱しています。実際にタスクベースのプログラミングとは何ですか。この用語は、ロックフリープログラミングと同じ意味ですか？これらの2つの同等の用語ですか、それらの間にリンクはありますか？

8 c++  multithreading  concurrency  c++11  multi-core 

これは私がいつも疑問に思っている一般的な質問です。 一般に、CPUが「while not true ...」ループなどを実行するスレッドを作成することは集中的ですか？ たとえば、次のようにするとします。 // pseudo-code new Thread(function() { while (!useHasDoneSomething) { // do nothing... } alert("you did something!"); } つまり、何かが発生するのを待つスレッドで実行されるコードの一部です。 何らかの理由で、これがCPUに圧力をかけると想像します。結局のところ、それは1つの小さなループですが、サイクルが行われた瞬間にループを再実行しています。これは、1ミリ秒に何回もサイクルを繰り返すことを意味しませんか？...ナノ秒あたり！？ オペレーティングシステムはプログラムとスレッドを「処理」しますよね？しかし、それでもループの実行にはかなりの注意が必要です。CPUが他に何もすることができない場合、CPUはそのループに集中し、それによってすべてのアイドル時間を消費しませんか？ すべて同じループを行うスレッドを1000個作成するとどうなりますか？それはパフォーマンス/ CPUサイクルにどのように影響しますか？ さらに、これはイベントが内部でどのように機能するのですか？Java、.NET、Javascriptなどのイベント（ボタンを押す、ウィンドウのサイズ変更など）を「聞いている」とき、ループするスレッドが作成されていますか？

8 performance  multithreading  loops 

入力をポートでリッスンするJavaプログラムがあります。入力に基づいて、Webサービスを呼び出し、成功/失敗をクライアントプログラムに返します。 クライアント接続ごとにスレッドをフォークします。プログラムに接続するクライアントへの応答は迅速でなければなりません。 これらは私が検討している選択肢です 通常のスレッドを使用する と使用ExecutorServiceするnewFixedThreadPool と使用ExecutorServiceするnewCachedThreadPool 私がプールを検討している理由は、私のスレッドが短命であるためです-スレッドはWebサービスを呼び出し、クライアントに結果を返し、接続を閉じます。 newFixedThreadPool接続がキューでスレッドを取得するために待機しているため、私は正しいことだとは思いません。 newCachedThreadPoolスレッドが1分後に死ぬということを除いて、完璧でした。私の場合、接続のバーストが発生します。つまり、複数の接続があり、その後数分間停滞する可能性があり、その後再びバーストします。CachedThreadPool内のスレッドは停止し、再度作成する必要があると思います。この場合、場合によっては＃1のように動作する可能性があります。 理想的には、私はnewCachedThreadPool最小限にしたいと思っていました-つまり、スレッド数が決して20を下回らないという設定です。したがって、アイドル状態のスレッドは強制終了されますが、最小しきい値を下回ることは決してありません。 このようなものはありますか？または、より良い代替案はありますか？

8 java  multithreading 

コンテキスト：パイプラインモデルに従うマルチスレッド（Linux-C）アプリケーションに取り組んでいます。 各モジュールには、データの処理を行うプライベートスレッドとカプセル化されたオブジェクトがあります。各ステージには、次のユニットとデータを交換する標準形式があります。 アプリケーションはメモリリークがなく、データを交換するポイントでロックを使用してスレッドセーフです。スレッドの総数は約15で、各スレッドには1〜4個のオブジェクトを含めることができます。約25〜30個の奇妙なオブジェクトを作成します。これらすべてに重要なロギングが必要です。 私が見たほとんどの議論は、Log4Jのようなさまざまなレベルと、それ以外の翻訳です。本当に大きな問題は、全体的なロギングが実際にどのように行われるべきかについてです。 1つのアプローチは、すべてのローカルロギングが行うfprintfことstderrです。stderrはいくつかのファイルにリダイレクトされます。ログが大きくなりすぎると、このアプローチは非常に悪くなります。 すべてのオブジェクトが個々のロガーをインスタンス化する場合（そのうちの約30〜40）、ファイルが多すぎます。そして、上記とは異なり、イベントの真の順序についての考えはありません。タイムスタンプは1つの可能性ですが、照合するのはまだ面倒です。 グローバルロガー（シングルトン）のパターンが1つある場合、ログの作成でビジー状態になっている間、非常に多くのスレッドが間接的にブロックされます。スレッドの処理が重い場合、これは受け入れられません。 では、ロギングオブジェクトを構造化するための理想的な方法は何でしょうか。実際の大規模アプリケーションでのベストプラクティスにはどのようなものがありますか？ また、インスピレーションを得るために、大規模アプリケーションの実際のデザインのいくつかから学びたいと思っています。 ====== 編集： ここでの両方の答えに基づいて、私は今残っている質問です： ロガー（ロギングキュー）をオブジェクトに割り当てる場合のベストプラクティスは何ですか？それらがglobal_api（）を呼び出すか、ロガーがコンストラクターでロガーに割り当てられるかどうかです。オブジェクトが深い階層にある場合、この後のアプローチは面倒になります。それらがいくつかのglobal_api（）を呼び出している場合、それはアプリケーションとの一種のカップリングであるため、他のアプリケーションでこのオブジェクトを使用しようとすると、この依存関係がスローされます。これのためのよりきれいな方法はありますか？

8 design-patterns  multithreading  logging 

最適化が早すぎないという原則に従って、ソフトウェアの設計/開発のどの時点で、同時実行の機会について考え始めますか？ シングルスレッドのアプリケーションを作成し、プロファイリングを通じて、並列実行の候補となるセクションを特定することが1つの戦略となることはよく想像できます。私が少し見てきたもう1つの戦略は、タスクのグループごとにソフトウェアを検討し、独立したタスクを並列化することです。 もちろん、尋ねる理由の1つは、最後まで待ってソフトウェアをリファクタリングするだけで同時に動作する場合、可能な限り最悪の方法で構造化し、大きなタスクを抱えることになるということです。 設計で並列化を検討するときに、どのような経験が役立ちましたか？

8 development-process  multithreading  concurrency  parallelism 

注：質問はスタックオーバーフローフォーラムには適さないと見なされており、ここに投稿する必要があったため、これは再投稿です。元のトピックはあります。 その作業を実現するために、マルチスレッド、並列処理、および現在利用可能なライブラリについてお話ししたいと思います。特に、この概念を実現するための使いやすいライブラリ（以下を参照）が既に存在するのか、それとも作成する必要があるのか​​、そしてそれがどれほど難しいのかについて疑問に思っています。 私が探しているライブラリの目的： エンジニアや高卒者だけでなく、ほとんどの開発者がアクセスできます（これは、開発者がそれを恐れずに使用したいことを意味します）。 C ++開発者が利用可能 ポータブル（Windows、Mac OS X、Linuxから始めて、モバイルデバイスに拡張） 軽量 使いやすい（アクセシビリティに関連） 私が探している最も重要な機能： タスクの並列処理 タスクのキャンセル（ソフトで突然の方法） タスクの依存関係 既存の関連ライブラリ： スレッドビルディングブロック：使用が非常に複雑で、制限のあるライセンス（GPL /商用）、これは私が見つけた唯一のライブラリで、探しているすべての機能が含まれています Grand Central Dispatch：現在移植性がなく、複雑すぎず、タスクのキャンセルなし（開始後）、タスクの依存関係なし、自動依存関係サポートなし（手動のみ） PFunc：Unixのみ、まだ少し複雑、タスクの依存関係なし、タスクのキャンセルなし Microsoft Task Parallel Library：MSプラットフォームと.NETのみ、ハードキャンセルなし、制限された手動のタスク依存関係（1つのタスクが他の複数のタスクを起動することはできません） OpenCL：現在、すべてのプラットフォームで使用できるわけではありません。GPU並列タスクライブラリほどではありません（希望するほど高レベルではありません）。 OpenMP：Visual Studioの無料バージョンを除いて広くサポートされており、タスクのキャンセルや自動タスクの依存関係はありません これらすべてについてどう思いますか？これらのニーズに対応するライブラリが少ないのはなぜだと思いますか？それとも私はいくつかの素晴らしい図書館を見逃しましたか？そして、それはそれを達成するにはあまりにも多くの仕事を意味すると思いますか？それとも十分に面白くないですか？私が書いた不足は、いくつかの検索で判明したものであり、私はこれらのライブラリの専門家ではありません。 このライブラリの最終的な目的は、たとえそれが夢であったとしても、シーケンシャルプログラミングで通常行うのと同じくらい簡単に並列化された方法でプログラミングすることです。 セイロ

8 c++  multithreading  accessibility  portability  parallel-programming 

さて、私は今日これについて考えていました、そして私はそれについて完全に主観的でバイアスのある意見を求めるようになりました。逆説的に、これにもかかわらず、私はそれが炎戦の飼料でもないと思います。完全に文明化された会話の余地はあると思います-Vim対Emacsはほとんどありません。 私は多くの並行処理の抽象化、特にスレッドの上に構築されたものを使用しました。メッセージパッシング、デフォルトでは不変、デフォルトではスレッドローカル、その他のいずれでも、それらの間には大きな傾向があります。 トレンドは、データ共有を暗黙的ではなく明示的にすることで、スレッドの考え方を逆転させているというものです。つまり、特に指定しない限り、すべてのデータは共有されません。これは、Javaなどの言語で見られる従来のスレッド化とは逆です。（ただし、Javaは独自の高レベルの同時実行抽象化をサポートしていることを知っています。）たとえば、メッセージを明示的に渡します。どの変数がスレッドローカルであるかを明示的に指定します。変更可能な変数を明示的に指定します。これらは、いくつかの言語で見られるほんの一例です。 この並行性の簡単なスタイルは現代のコンセプトだと思いました。間違えた。最近fork（）やpipe（）のようなUNIXのおもちゃをいじり始めましたが、UNIXの開始以来、簡単で明示的な並行処理メカニズムが存在していることを知ってショックを受けました。 70年代のC + UNIXが同時実行性を多くの最新のトレンディなスレッド化メカニズムよりもはるかに簡単にすることを実現することには、少し奇妙な点があります。 だから、ここで私が疑問に思っているのは...これらの現代のスレッド抽象化は、すべての明示性とデフォルトで共有されない特性を備えたスレッド上でUNIXスタイルのプロセスを単にエミュレートしようとしているのでしょうか？STMのようないくつかのメカニズムがDBスタイルのトランザクションのようなものを提供することは確かですが、それは本当に並行性のための現代的で革新的なソリューションですが、ほとんどの場合、UNIXプログラマーが昔行っていたことを行う新しい方法のように見えます。 言うまでもなく、私はUNIXのファンではなく、想像力を伸ばしているわけでもありません。プロセスは多くのプラットフォームで初期化するためにスレッドよりもはるかに遅いことを認識していますが、これは概念的に述べています。

8 performance  multithreading  concurrency 

ファイルをネットワーク共有の場所にアップロード（およびファイルに対して他の操作を実行）するために使用されるユーティリティがあります。 ファイルサイズは、数MBから500 MBに変化する傾向があります。 共有の場所にファイルをアップロードするときにマルチスレッドをサポートする必要があるという提案が出ました-バイトチャンクで行う必要はありません-各スレッドは1つのファイルを選択してアップロードを試行する必要があります。 マルチスレッドがこのようなIO操作を高速化できるかどうかは、私にはよくわかりません。私の勘は有効ですか？ 確かにこの機能を構築する必要がある場合、ファイルコピーエンジンの設計にはどのようなアプローチが適しているのでしょうか。 robocopyなどのツールを使用することは理にかなっていますか（私はマルチスレッドをサポートする新しいバージョンを読みました）。 編集：遅延といくつかの重要な情報の欠落についての謝罪。 このユーティリティはC＃（.Net 2.0）を使用して構築されており、今後のアップデートでも.Netを使用する必要があります（フレームワークのバージョンは制約ではありません）。ユーティリティはユーザーのマシンにインストールされます（WinXPの場合は約20）。ターゲット共有はWin2k3サーバー上にあります。 編集2：TPLを介したファイルのアップロードを実装する簡単なアプリケーションでいくつかのテストを実行することを決定しました。この分析を投稿して、先に進むかどうかを決定します。皆様のご協力に感謝いたします。

8 design  .net  multithreading  file-handling