0

これは私が自分のスレッドを管理しようとしている方法です

-(void)ExecuteThread {
  @autoreleasepool {

    bInsideDifferentThread = YES;
    //some code...
    bInsideDifferentThread = NO;
  }
  [NSThread exit];
}

-(void)ThreadCallerEvent {
  NSThread *myThread = [[NSThread alloc] initWithTarget:self     selector:@selector(ExecuteThread) object:nil];
  if (!bInsideThread)
  [myThread start];
  else
  {
    [myThread cancel];
  }
}

作業が完了するまでスレッドを開始したくないので、このようにします。問題は、これが割り当てられた解放されていないメモリからリークを生成していることです[NSThread init]

この問題を解決する方法のアイデアはありますか?

4

1 に答える 1

0

あなたのものと同様のフラグメントを実行しましたが、リークを検出できませんでした。しかし、文脈はほぼ確実に異なります。myThread範囲外になったときに、ARCがあなたの例で何をしているのか本当にわかりません。使用する典型的なパターンは次のNSThreadとおりです。

[NSThread detachNewThreadSelector:@selector(executeThread)
                         toTarget:self
                       withObject:nil];

その場合、デタッチしているスレッドを直接処理する責任はありません。 (注: メソッド名を、Cocoa で推奨されるメソッドおよび変数の命名規則であるキャメル ケースを使用するように変更しました。)

上記のすべてが述べたように、スレッドの管理は、並行設計を実現するための推奨される方法ではなくなりました。それは完全に受け入れられます。しかし、Apple は開発者に GCD への移行を奨励しています。同時に実行する必要がある作業単位の観点から考える方がはるかに優れています。

この場合のニーズをより深く理解しないと、スレッドを直接操作することで得られる利点があるとしても、それを知ることは困難です。しかし、同時キュー/GCD をより詳しく検討することを検討します。おそらく、次のようなものを単純に使用できます。

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    //  do your background work
});

並行性のためのより明確な設計と、現在発生しているメモリ管理の問題を回避することの両方を実現します。

于 2012-11-23T01:54:29.487 に答える