Professional Web Applications Themes

Yield with NSThread - Mac Programming

Hi, I'm trying to block the execution of some code until a thread has finished a job. Blocking is easy, however I'd like to 'freeze' the waiting thread for a few milliseconds in order for the job thread to get as uch cpu as needed. NSThread only provides freezing methods with NSDate as parameters, which means the minimum freeze time is one second which is much more than what I need. What would be a good strategy to do in Cocoa what Yield() does in Carbon ? Eric...

  1. #1

    Default Yield with NSThread

    Hi,

    I'm trying to block the execution of some code until a thread has finished a
    job. Blocking is easy, however I'd like to 'freeze' the waiting thread for a
    few milliseconds in order for the job thread to get as uch cpu as needed.

    NSThread only provides freezing methods with NSDate as parameters, which
    means the minimum freeze time is one second which is much more than what I
    need.

    What would be a good strategy to do in Cocoa what Yield() does in Carbon ?

    Eric

    Eric Guest

  2. #2

    Default Re: Yield with NSThread

    dans l'article BBF78FD8.16D85%fr, Eric VERGNAUD à
    fr a écrit le 6/12/03 13:53:
     

    By the way, I had a look at NSConditionLock, but couldn't fnd a strategy to
    use it in my case. Typically, the jobs thread has a certain count of atomic
    tasks to perform. The waiting thread needs to wait for that count to become
    0. Since the locker can't change the condition of a NSConditionLock while
    it's locked, I don't see how I could use this.

    Eric

    Eric Guest

  3. #3

    Default Re: Yield with NSThread

    In article <BBF7938E.16D90%fr>,
    Eric VERGNAUD <fr> wrote:
     

    You shoul be able to make this work correctly with a simple NSLock.
    Acquire the lock, launch the thread, and try to acquire the lock again.
    The worker thread works, and when it finishes, it releases the lock. The
    main thread then immediately releases the lock. Of course, this makes me
    wonder why you don't just run the work in the main thread if you're
    waiting for it to finish. Or you can use pthread condition variables and
    mutexes; NSThreads exist on top of pthreads, so all pthread functions
    work.

    If you prefer a simply give up the processor for a small amount of time,
    usleep() should do what you want.
    Michael Guest

  4. #4

    Default Re: Yield with NSThread

    dans l'article mail-F954B5.15223906122003localhost, Michael Ash à
    com a écrit le 6/12/03 15:22:
     
    >
    > You shoul be able to make this work correctly with a simple NSLock.
    > Acquire the lock, launch the thread, and try to acquire the lock again.
    > The worker thread works, and when it finishes, it releases the lock. The
    > main thread then immediately releases the lock. Of course, this makes me
    > wonder why you don't just run the work in the main thread if you're
    > waiting for it to finish. Or you can use pthread condition variables and
    > mutexes; NSThreads exist on top of pthreads, so all pthread functions
    > work.
    >
    > If you prefer a simply give up the processor for a small amount of time,
    > usleep() should do what you want.[/ref]

    I need a thread so the UI stays reactive. Many user events are acceptable:
    scroll, resize, cancel etc... However I cannort sort (as a response in a
    list header) until the list is loaded (which is done in the thread).

    Usleep is exactly what I'm looking for. Thanks.

    Eric

    Eric Guest

  5. #5

    Default Re: Yield with NSThread

    In article <BBF7AC8B.16DA2%fr>,
    Eric VERGNAUD <fr> wrote:
     

    If you just want to spawn off a worker thread and then have something
    happen in the main thread when it's done, just use
    performSelectorOnMainThread:withObject:waitUntilDo ne: at the end of the
    worker thread. No need to around with sleeps or locks or anything
    like that.
    Michael Guest

  6. #6

    Default Re: Yield with NSThread

    dans l'article mail-BFCF75.17312906122003localhost, Michael Ash à
    com a écrit le 6/12/03 17:31:
     
    >
    > If you just want to spawn off a worker thread and then have something
    > happen in the main thread when it's done, just use
    > performSelectorOnMainThread:withObject:waitUntilDo ne: at the end of the
    > worker thread. No need to around with sleeps or locks or anything
    > like that.[/ref]

    No that's not what I'm looking for. There's only one action among 100 that
    requires completion. It can only be triggered by the user after the other
    thread is launched. usleep is just what I need, however I read in the docs
    hat is puts the process to sleep. Is this a doc bug ? I only want to put the
    thread to sleep.

    Eric

    Eric Guest

  7. #7

    Default Re: Yield with NSThread

    In article <BBF78FD8.16D85%fr>,
    Eric VERGNAUD <fr> wrote:
     

    I'm not going to say that using sleepUntilDate: is the best option, but
    I will point out that the minimum sleep time using it is much smaller
    than one second. Take a closer look at the docs. NSDate does store time
    as a number of seconds from a reference date, but it doesn't use an
    integer type to hold it. It uses a double-precision float.
    Gregory Guest

  8. #8

    Default Re: Yield with NSThread

    In article <BBF7DC24.16DC6%fr>,
    Eric VERGNAUD <fr> wrote:
     
    >
    > No that's not what I'm looking for. There's only one action among 100 that
    > requires completion. It can only be triggered by the user after the other
    > thread is launched. usleep is just what I need, however I read in the docs
    > hat is puts the process to sleep. Is this a doc bug ? I only want to put the
    > thread to sleep.[/ref]

    I'm having trouble understanding just what's going on. In general, it's
    a bad idea to poll anything if it's not necessary, and it's not normally
    necessary in this sort of situation, but since I don't really get what
    you're doing, I don't know. :P What is the sequence of events? The user
    starts process A, then while process A is running, if he start process
    B, it should wait until A finishes, is that it?

    As far as *sleep() halting the entire process or not, this is not
    exactly a doc bug, but sort of a doc ambiguity. Threads mostly act like
    separate processes which share memory. Calls which affect shared
    entities, like file descriptors or memory, will affect the process
    globally. Scheduling is handled thread-per-thread, so anything which
    affects scheduling should only affect the calling thread.
    Michael Guest

  9. #9

    Default Re: Yield with NSThread

    dans l'article mail-05284C.20443006122003localhost, Michael Ash à
    com a écrit le 6/12/03 20:44:
     

    Yes, that's it.

    I hate polling too, so I had a look at conditional locks but it doesn't seem
    appropriate. Since the waiting period is typically 1/10th of a second and
    should never exceed 10 seconds, it's not as much as a problem as using
    polling for a watch folder.

    Eric

    Eric Guest

  10. #10

    Default Re: Yield with NSThread

    dans l'article attbi.com,
    Gregory Weston à com a écrit le 6/12/03 20:36:
     
    >
    > I'm not going to say that using sleepUntilDate: is the best option, but
    > I will point out that the minimum sleep time using it is much smaller
    > than one second. Take a closer look at the docs. NSDate does store time
    > as a number of seconds from a reference date, but it doesn't use an
    > integer type to hold it. It uses a double-precision float.[/ref]

    I'll try it, thanks.

    Eric

    Eric Guest

  11. #11

    Default Re: Yield with NSThread

    In article <BBF7F3D8.16E30%fr>,
    Eric VERGNAUD <fr> wrote:
     
    >
    > Yes, that's it.
    >
    > I hate polling too, so I had a look at conditional locks but it doesn't seem
    > appropriate. Since the waiting period is typically 1/10th of a second and
    > should never exceed 10 seconds, it's not as much as a problem as using
    > polling for a watch folder.[/ref]

    Then it depends on whether or not it is acceptable for the main thread
    to block when the user starts process B. I assume that it is, otherwise
    you'd be using a timer to poll.

    You should be able to do this with an NSConditionLock. Code something
    along these lines should work (with the caveat that I haven't tried it):

    Main thread:
    spawn worker thread
    [conditionLock lockWhenCondition:WORK_THREAD_FINISHED]; // wait here
    [conditionLock unlock]; // relinquish the lock

    Worker thread:
    work, work, work
    [conditionLock lock]; // grab the lock so we can then unlock it
    [conditionLock unlockWithCondition:WORK_THREAD_FINISHED];
    exit
    Michael Guest

  12. #12

    Default Re: Yield with NSThread

    > Then it depends on whether or not it is acceptable for the main thread 

    It's not only acceptable, it's mandatory. If the user clicks on a list
    header, he expects the list to be sorted, so he definintely can and has to
    wait for the list to be loaded.
     

    Seems feasible, although not very intuitive. I'll try it.

    Thanks,

    Eric

    Eric Guest

Similar Threads

  1. break in yield/block
    By matt in forum Ruby
    Replies: 7
    Last Post: November 21st, 08:56 PM
  2. Thoughts on yield
    By Nolan J. Darilek in forum Ruby
    Replies: 16
    Last Post: September 30th, 05:05 PM
  3. Replies: 6
    Last Post: July 17th, 01:19 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