問題タブ [reentrancy]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
4 に答える
895 参照

linux - Linux カーネル コードが再入可能であることを同僚に納得させるにはどうすればよいですか?

ええ、私は知っています... 一部の人々は、私たちの残りの人にとって自然に聞こえることを納得させるのが難しい場合があります。今すぐあなたの助けが必要です SO コミュニティ (または、すぐに郵送します..)

私の同僚の 1 人は、おそらく 7 年前に Linux カーネル コードに興味を持ったときにどこかで読んだので、Linux カーネル コードは再入可能ではないと確信しています。おそらくその時点での読みは正しかったのでしょう。マルチコア アーキテクチャはしばらく前にはあまり普及しておらず、当初の Linux プロジェクトは完全に適切に作成されておらず、すべてのファンシーな機能を完全に備えていなかったことを思い出してください。

今日は違います。同じアーキテクチャで並行して実行されている異なるプロセスから同じシステム コールを呼び出しても、未定義の動作が発生しないことは明らかです。Linux カーネルは現在広く普及しており、マルチコア アーキテクチャで実行されているにもかかわらず、その信頼性で知られています。それが今のところの私の主張です。しかし、それを客観的に証明するためにあなたは何をしますか?

私は彼に Linux カーネル ( lxr Web サイト) の関数を、mutex_lock() システム コールとして見せようと考えていました。すべてが並行環境で機能するように調整されています。しかし、コードは初心者にとってそれほど明白ではない可能性があります(私のように)。

私を助けてください.. ;-)

0 投票する
1 に答える
3202 参照

java - ReentrantLock 経由でアクセスされるフィールドには volatile キーワードが必要ですか?

私の質問は、ReentrantLock の使用が、synchronized キーワードが提供するのと同じ点でフィールドの可視性を保証するかどうかについてです。

たとえば、次のクラスAでは、synchronized キーワードが使用されているため、フィールドsharedDataを volatile と宣言する必要はありません。

ただし、ReentrantLock を使用する次の例では、フィールドに volatile キーワードが必要ですか?

いずれにせよ volatile キーワードを使用してもパフォーマンスへの影響はごくわずかであることはわかっていますが、それでも正しくコーディングしたいと考えています。

0 投票する
5 に答える
30044 参照

c# - コールバックメソッドでタイマーを停止する

10ミリ秒ごとに適切なイベントハンドラー(コールバック)を呼び出すSystem.Threading.Timerがあります。メソッド自体は再入可能ではなく、10ミリ秒より長くかかる場合があります。したがって、メソッドの実行中にタイマーを停止したいと思います。

コード:

MSDNは、コールバックメソッドがスレッドプールとは別のスレッドで(タイマーが起動するたびに)呼び出されると述べています。つまり、メソッドの最初にタイマーを停止しても、最初のインスタンスがタイマーを停止する前に、タイマーが起動してメソッドの別のインスタンスを実行することを必ずしも妨げることはありません。

タイマー(または再入可能でないメソッド自体)をロックする必要がありますか?コールバック(および非再入可能)メソッドの実行中にタイマーが起動するのを防ぐ正しい方法は何ですか?

0 投票する
3 に答える
595 参照

multithreading - 同時実行/再入可能 /ThreadSafe/?

スレッドの安全性、再入可能性に関する質問について、ここで提供された多くの回答を読みましたが、それらについて考えると、さらにいくつかの質問が頭に浮かんだので、この質問/s.

1.) *.exe という実行可能プログラムが 1 つあります。このプログラムをコマンド プロンプトで実行し、その実行中に別のコマンド プロンプトで同じプログラムを実行すると、どのような状況で結果が破損する可能性があるか、つまり、このプログラムのコードが再入可能であるか、または単独でスレッドセーフ?

2.) 再入可能性を定義する際に、既に実行中のルーチンに再入できると言い、どのような状況で関数に再入できるか (再帰ルーチンであることは別として、ここでは再帰実行については話していません) . 同じコードを再度実行するには、何らかのスレッドが必要です。または、その関数に再び入るにはどうすればよいでしょうか?

3.) 実際のケースでは、2 つのスレッドが同じコードを実行します。つまり、同じ機能を実行します。マルチスレッドのアイデアは、異なる機能を同時に(異なるコア/プロセッサで)実行することだと思いました。

これらのクエリが異なっているように見える場合は申し訳ありませんが、SO に関するスレッドセーフな Vs リエントラントの投稿について読んだときに、それらはすべて私に思い浮かびました。したがって、それらをまとめました。

任意のポインター、読み物をいただければ幸いです。

ありがとう、

-広告。

0 投票する
7 に答える
3463 参照

recursion - 再帰関数はリエントラントですか

私は、各再帰呼び出し/演算の結果を保持する静的変数の使用を含む多くの再帰関数(主に階乗、数値の桁の合計などのいくつかの数学演算の計算に使用されます)を見てきました。後続の呼び出しに使用します。

そのため、再帰関数は非賃貸であり、スレッドセーフではありません。

静的変数を必要としない再帰関数の他のユースケースはありますか?

0 投票する
2 に答える
3465 参照

parsing - リエントラントパーサーとは何ですか?

誰かが私にこれを説明できますか?特に、次の違いは次のとおりです。

http://github.com/whymirror/gregおよびhttp://piumarta.com/software/peg/

前者は後者のリエントラントバージョンです。

0 投票する
1 に答える
3192 参照

c# - Visual Studioデバッガーによって表示される「再入可能性が検出されました」という警告を修正するにはどうすればよいですか?

ユニットテストをデバッグモードで実行すると、ある時点でVisualStudioデバッガーが中断して再入可能性MDAが表示されます。リンクされた記事では、これは、ベクトル化された例外ハンドラーなどの低レベルのオペレーティングシステム拡張ポイントが管理対象アプリケーションコードにコールバックしたときに発生することを説明しています。

どうやらこれはヒープの破損やその他の深刻な問題を引き起こす可能性があるので、私は間違いなくそれを修正したいと思います。

この警告が表示されたポイントでスタックトレースを確認していますが、ここでどの「低レベルのオペレーティングシステム拡張ポイント」が関係しているかを特定するのに問題があります。System.Windows.Forms.Cursors.VSplitmstestとgetterの呼び出しによって引き起こされたもの以外に、管理されていない/管理された遷移は表示されません。また、単体テストからそのゲッターを呼び出すだけでは、警告をトリガーするのに十分ではないようです。

ここで何を間違えたのですか、どうすれば修正できますか?

0 投票する
1 に答える
7860 参照

thread-safety - Flex で再入可能なレクサーを作成する

フレックス初心者です。フレックスを使用して単純な再入可能なレクサー/スキャナーを作成しようとしています。レクサーの定義は以下のとおりです。以下に示すように、コンパイル エラーが発生します (yyg の問題)。

reentrant.l:

コンパイル エラー:

0 投票する
8 に答える
94238 参照

c++ - リエントラント関数とは正確には何ですか?

ほとんど 場合 リエントラントの定義はウィキペディアから引用されています。

コンピュータプログラムまたはルーチンは 、前の呼び出しが完了する前に安全に再度呼び出すことができる場合(つまり、同時に安全に実行できる場合)、再入可能であると説明されます。再入可能であるためには、コンピュータプログラムまたはルーチン:

  1. 静的(またはグローバル)非定数データを保持してはなりません。
  2. アドレスを静的(またはグローバル)非定数データに返さないでください。
  3. 呼び出し元から提供されたデータに対してのみ機能する必要があります。
  4. シングルトンリソースへのロックに依存してはなりません。
  5. 独自のコードを変更してはなりません(独自のスレッドストレージで実行する場合を除く)
  6. 再入可能でないコンピュータプログラムまたはルーチンを呼び出さないでください。

安全に定義する方法は?

プログラムを同時に安全に実行できる場合、それは常に再入可能であることを意味しますか?

コードの再入可能機能をチェックする際に留意する必要がある、言及された6つのポイント間の共通のスレッドは正確には何ですか?

また、

  1. すべての再帰関数はリエントラントですか?
  2. すべてのスレッドセーフ機能は再入可能ですか?
  3. すべての再帰的でスレッドセーフな関数は再入可能ですか?

この質問を書いているときに、1つのことが頭に浮かびます。リエントラントスレッドセーフなどの用語は絶対的なものですか。つまり、具体的な定義が固定されているのでしょうか。そうでない場合、この質問はあまり意味がありません。