Professional Web Applications Themes

Problem with NSThread and usleep - Mac Programming

Hi, I have the following problem: - my Cocoa app creates a NSThreads - this threads needs to sleep periodically, this is done using usleep - the app and the thread share a NSLock - if I quit my app while the thread is sleeping, the app disposes the lock before the thread wakes up. When the thread wakes up, it tries to access the lock which no longer exists and crashes I do not want to wait for the thread to stop sleeping because this could be very long How can I wake up the sleeping thread from the ...

  1. #1

    Default Problem with NSThread and usleep

    Hi,

    I have the following problem:
    - my Cocoa app creates a NSThreads
    - this threads needs to sleep periodically, this is done using usleep
    - the app and the thread share a NSLock
    - if I quit my app while the thread is sleeping, the app disposes the lock
    before the thread wakes up. When the thread wakes up, it tries to access the
    lock which no longer exists and crashes

    I do not want to wait for the thread to stop sleeping because this could be
    very long
    How can I wake up the sleeping thread from the app ?

    Eric

    Eric Guest

  2. #2

    Default Re: Problem with NSThread and usleep

    In article <BC64AD3D.1B407%fr>,
    Eric VERGNAUD <fr> wrote:
     

    Instead of usleep, use an NSConditionLock. Use
    lockWhenCondition:beforeDate: to sleep, and set the condition from your
    main thread before exiting. This is the solution I use in my app for a
    similar situation.

    Alternatively, send a signal to the thread using pthread_kill(). This
    may be hard to make perfectly safe, because you'll have a small window
    between when you check for whether you should quit the thread and when
    you start sleeping, where the signal could be delivered and have no
    effect. (Wandering a bit off-topic: is there a way to do this in a safe
    manner? I've seen this idiom used to flag a config file reload in apps
    that block in select(), but there's always this small window between the
    check and the select() call where the app would end up blocking anyway.)
    Michael Guest

  3. #3

    Default Re: Problem with NSThread and usleep

    dans l'article mail-7DDDA6.12120127022004localhost, Michael Ash à
    com a écrit le 27/02/04 12:12:
     
    >
    > Instead of usleep, use an NSConditionLock. Use
    > lockWhenCondition:beforeDate: to sleep, and set the condition from your
    > main thread before exiting. This is the solution I use in my app for a
    > similar situation.
    >
    > Alternatively, send a signal to the thread using pthread_kill(). This
    > may be hard to make perfectly safe, because you'll have a small window
    > between when you check for whether you should quit the thread and when
    > you start sleeping, where the signal could be delivered and have no
    > effect. (Wandering a bit off-topic: is there a way to do this in a safe
    > manner? I've seen this idiom used to flag a config file reload in apps
    > that block in select(), but there's always this small window between the
    > check and the select() call where the app would end up blocking anyway.)[/ref]

    Thanks Michael.

    Eric Guest

  4. #4

    Default Re: Problem with NSThread and usleep

    dans l'article BC655E6F.1B54F%fr, Eric VERGNAUD à
    fr a écrit le 27/02/04 20:51:
     [/ref]

    This worked out very well. Thanks again Michael.

    Eric

    Eric Guest

  5. #5

    Default Another synchronization issue

    Hi,

    On Windows, there are special locks called semaphores. The nice thing about
    semaphores is that they allow to specify a number of concurrent accesses
    before actually performing the lock.

    This can be useful for a thread pool, which you do not whant to exceed a
    certain size.

    A typical scenario looks like the following:

    Main thread:
    =========

    Int maxallowed = 3;
    Semaphore s = new Semaphore(maxallowed );

    For(;;)
    {
    job = GetAjobToDoInAThread();
    s->Lock();
    job->DoItInAThread(s);
    }

    Job Thread
    ========

    Job::DoIt(Semaphore s)
    {
    // do the job here
    s->Unlock();
    }

    In this scenario, 3 jobs can be run simultaneously. In that case, the main
    thread, automatically blocks until ANY of these 3 jobs is finished.

    I'm sure I can implement this using NSConditionalLock, but I can't figure
    out how. I can't find any other objects in Foundation to do this.

    Can someone help ?

    Eric

    Eric Guest

  6. #6

    Default Re: Another synchronization issue

    OK, I found what I was looking for in MPServices.
    Wonder why this hasn't been Cocoa'ed;

    Eric
     

    Eric Guest

  7. #7

    Default Re: Another synchronization issue

    In article <BC65C2B3.1B56D%fr>,
    Eric VERGNAUD <fr> wrote:
     

    Check out pthreads, the native thread implementation.

    --
    Mike Cohen - mike3k <at> onepost <dot> net
    Personal: http://www.mc-development.com/
    Mac News: http://www.macmegasite.com/
    Mike Guest

  8. #8

    Default Re: Another synchronization issue

    dans l'article
    bellsouth.net, Mike Cohen à
    com a écrit le 29/02/04 0:51:
     
    >
    > Check out pthreads, the native thread implementation.[/ref]

    I did, but couldn't find what I was looking for. Sem_ is not avail on OS
    X, says the doc.

    Eric

    Eric Guest

Similar Threads

  1. Yield with NSThread
    By Eric in forum Mac Programming
    Replies: 11
    Last Post: December 6th, 09:38 PM
  2. usleep and alarm clock
    By Digital Puer in forum UNIX Programming
    Replies: 1
    Last Post: July 27th, 03:58 AM
  3. note 33583 added to function.usleep
    By me@rack1.php.net in forum PHP Notes
    Replies: 1
    Last Post: July 1st, 12:15 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139