2016-10-29 12 views
2

私はsysfsインターフェイスを持っています。このインターフェイスは、特定の条件が満たされるまで書き込みタスクが実行されないようにする必要があります。タスクがスケジュールされないようにする

非遮断のための条件は次の形式になりますので、状態の性質、私はschedule_timeoutを使用する権利のメカニズムであるとは思わないの

if(tsk->wait_time > MAX_WAIT_PERIOD || tsk->condition_met) { 
    // Unblock task and let it run again 
} 

。または少なくとも、私はそれを使用する方法を考え出しておらず、待ち時間をキャンセルする/適切にプロセスに信号を送る。

私は手動でもsysfs書き込み時に次の操作を行って試してみました:条件が満たされたときに

... 
__set_current_state(TASK_INTERRUPTIBLE); 
schedule(); 
... 

そして:

if(tsk->wait_time > MAX_WAIT_PERIOD || tsk->condition_met) { 
    set_task_state(tsk, TASK_RUNNING); 
} 

これは、その結果:どのように考えるBUG: scheduling while atomic: dummyThread/2622/0x00000002
schedule_timeoutほとんど同じ同じ論理、私はそれも同じの原因と思われると思うBUG: scheduling while atomic: ... erro r。

また、deactivate_taskactivate_taskメソッドを試しましたが、スケジューラのpick_next_taskチェーンでカーネルパニックが発生しました。必要に応じて、これを再実装してスタックトレースを送信します。

特定の条件が満たされるまでタスクが実行されないようにする正しい方法は何ですか?

+0

愚かな質問かもしれませんが、私が理解しているところでは、書き込みを試みるユーザースペースプロセスは、許可する前に再度書き込むことができません。もしそうなら、なぜwriteメソッドのI/Oをブロックしないのですか?あなたの条件が満たされるまでライターをブロックするようなやり方で、データを利用できるようにすることができます。 O_NONBLOCKが指定されていない限り、I/O操作(書き込み)が既にブロックされていることを知っているので、タスク状態を手動で変更するのは少し奇妙なようです。その後、簡単なセマフォーが使えますか? –

+0

私は同意します。それは簡単だったはずです。しかし、セマフォを取得すると、結果的に 'schedule()'が呼び出され、私の場合は 'BUG:atomic while:scheduling ... 'が発生します。 –

答えて

1

schedule_timeout()は、タイムドウェイトのための良好な低レベル関数です。

しかし、set_task_state()は目覚めのために悪い選択です。この機能は主に現在のスレッドです。代わりに、wake_up_processまたはwake_up_stateを使用してください。

+0

これは機能します! 'fs/proc/base.c'の別の関数から借りたボイラープレートコードは、' get_proc_task() 'と' task_lock() 'の中で' schedule_timeout'ロジックを呼び出していました。一旦私のコードをこれ以外の場所に移動させたなら、バグ:原子の間のスケジューリングを引き起こすことなく、 –

関連する問題