Re: QNX - GNUstep and Objective C

[bbceler]

I compiled the newest version gnustep - base from svn. 
Compilation passed without problems and to tests I chose program
diningPhilosophers from Examples.
To comparison I used analogous program compiled by compiler ada - gnat4.2.2
and the compiler of language the Vala.
CPU: Intel Core2 Quad 2.40GHz OS: QNX 6.4.1 
diningPhilosophers:
        pid name                   sid          start time   utime    stime
 9420869 diningPhilosophers  495654 Oct 31 22:49 25.125  5.004
In Instance methods 
- (void)sitAtChair:(NSNumber *) 
I exchanged expression: for { and = 0;and < 10000  on expression usleep(
100000 ); 
         pid name                      sid          start time   utime  
stime
10621002 diningPhilosophers_2  495654 Oct 31 22:54 26.600  0.001
when 
        * start time  the time and date that the process was started
        * utime  the number of CPU seconds consumed by the process
        * stime  the number of CPU seconds consumed by the kernel on behalf
of the process
                
And now program compiled using the compiler of the language Vala.
         pid name                 sid          start time   utime  stime
14803031 ./philosofers       495654 Oct 31 23:15  0.004  0.000

and Ada - gnat4.2.2
         pid name                   sid       start time   utime  stime
24789088 ./diners            495654 Oct 31 23:30  0.014  0.004

This looks from the point of the sight of threads:

    Show thread times.
         pid tid name                  STATE        start time     thread
start   sutime
11956301   1 diningPhilosophers RUNNING     Oct 31 23:00 Oct 31 23:00  7.958
11956301   2 diningPhilosophers MUTEX       Oct 31 23:00 Oct 31 23:00  2.221
11956301   3 diningPhilosophers READY        Oct 31 23:00 Oct 31 23:00 
2.127
11956301   4 diningPhilosophers MUTEX       Oct 31 23:00 Oct 31 23:00  2.220
11956301   5 diningPhilosophers READY       Oct 31 23:00 Oct 31 23:00  2.015
11956301   6 diningPhilosophers MUTEX       Oct 31 23:00 Oct 31 23:00  2.075
..............................     
         pid tid name                     STATE          start time    
thread start    sutime
11620427   1 diningPhilosophers_2 RUNNING       Oct 31 22:58 Oct 31 22:58 
8.277
11620427   2 diningPhilosophers_2 MUTEX         Oct 31 22:58 Oct 31 22:58 
0.000
11620427   3 diningPhilosophers_2 NANOSLEEP   Oct 31 22:58 Oct 31 22:58 
0.000
11620427   4 diningPhilosophers_2 MUTEX         Oct 31 22:58 Oct 31 22:58 
0.000
11620427   5 diningPhilosophers_2 MUTEX         Oct 31 22:58 Oct 31 22:58 
0.000
11620427   6 diningPhilosophers_2 NANOSLEEP   Oct 31 22:58 Oct 31 22:58 
0.000
start_time  The thread's starting time, in nanoseconds..    
    sutime  The thread's system plus user running time, in nanoseconds.
diningPhilosophers:
         stack tid   pid-tid       STATE       cpu prio kernel call
 12K(516K)*   1  12689488-0 RUNNING       3  10r
4096(132K)    2  12689488-0 RUNNING       1  10r
4096(132K)    3  12689488-0 MUTEX         2  10r sync_mutex_lock
4096(132K)    4  12689488-0 READY          2  10r
4096(132K)    5  12689488-0 MUTEX         3  10r sync_mutex_lock
4096(132K)    6  12689488-0 MUTEX         0  10r sync_mutex_lock
diningPhilosophers_2:
         stack tid pid-tid         STATE       cpu prio kernel call
 16K(516K)*   1  13897811-0 RUNNING       3  10r
4096(132K)    2  13897811-0 MUTEX         1  10r sync_mutex_lock
4096(132K)    3  13897811-0 NANOSLEEP   1  10r timer_timeout
4096(132K)    4  13897811-0 MUTEX         0  10r sync_mutex_lock
4096(132K)    5  13897811-0 MUTEX         0  10r sync_mutex_lock
4096(132K)    6  13897811-0 MUTEX         2  10r sync_mutex_lock

Vala
         pid tid name               STATE            start time     thread
start   sutime
17399899   1 ./philosofers      SIGWAITINFO Oct 31 23:19 Oct 31 23:19  0.002
17399899   2 ./philosofers      NANOSLEEP    Oct 31 23:19 Oct 31 23:19 
0.000
17399899   3 ./philosofers      NANOSLEEP    Oct 31 23:19 Oct 31 23:19 
0.000
17399899   4 ./philosofers      CONDVAR       Oct 31 23:19 Oct 31 23:19 
0.000
17399899   5 ./philosofers      CONDVAR       Oct 31 23:19 Oct 31 23:19 
0.000
17399899   6 ./philosofers      NANOSLEEP    Oct 31 23:19 Oct 31 23:19 
0.000

         stack tid pid-tid         STATE           cpu prio kernel call
 12K(516K)*   1  14442581-0 SIGWAITINFO   2  10r signal_waitinfo
4096(132K)    2  14442581-0 NANOSLEEP      2  10r timer_timeout
4096(132K)    3  14442581-0 NANOSLEEP      3  10r timer_timeout
4096(132K)    4  14442581-0 CONDVAR         0  10r sync_condvar_wa
4096(132K)    5  14442581-0 CONDVAR         0  10r sync_condvar_wa
4096(132K)    6  14442581-0 NANOSLEEP      3  10r timer_timeout

Ada - gnat4.2.2
         pid tid name              STATE             start time  thread
start   sutime
25940065   1 ./diners           CONDVAR     Oct 31 23:32 Oct 31 23:32  0.006
25940065   2 ./diners           CONDVAR     Oct 31 23:32 Oct 31 23:32  0.015
25940065   3 ./diners           CONDVAR     Oct 31 23:32 Oct 31 23:32  0.000
25940065   4 ./diners           CONDVAR     Oct 31 23:32 Oct 31 23:32  0.000
25940065   5 ./diners           CONDVAR     Oct 31 23:32 Oct 31 23:32  0.000
25940065   6 ./diners           CONDVAR     Oct 31 23:32 Oct 31 23:32  0.000
25940065   7 ./diners           CONDVAR     Oct 31 23:32 Oct 31 23:32  0.000

          stack tid pid-tid          STATE       cpu  prio kernel call
  12K(516K)*   1  20852829-0 CONDVAR       2  31o sync_condvar_wa
4096(2052K)    2  20852829-0 CONDVAR       2  31o sync_condvar_wa
4096(2052K)    3  20852829-0 CONDVAR       1  31o sync_condvar_wa
4096(2052K)    4  20852829-0 CONDVAR       3  31o sync_condvar_wa
4096(2052K)    5  20852829-0 CONDVAR       1  31o sync_condvar_wa
4096(2052K)    6  20852829-0 CONDVAR       0  31o sync_condvar_wa
4096(2052K)    7  20852829-0 CONDVAR       2  31o sync_condvar_wa

diningPhilosophers.m
..............
int main()
{
  NSAutoreleasePool     *arp = [NSAutoreleasePool new];
  int i;
..............
  for (i = 0;i < 5; ++i)
          [forks[i] unlockWithCondition:FOOD_SERVED];

  while (1);
  [arp release];
}

Executing the statement while(1); in the main thread of the program
diningPhilosophers makes 
the loop of the expectation and such large time sutime results from here.
In Vala this looks as follows:

static int main (string[] args) {

    if (!Thread.supported ()) {
        error ("Cannot run without thread support.");
    }
..................
    new MainLoop (null, true).run ();

    return 0;
}

In ada/gnat this realized using the mechanism of tasks.
Someone could me maybe prompt as realize the loop of the expectation in
GNUstep better. 

And as you can see Vala and gnat they use the mechanism condvare to the
synchronisation of threads.
GNUstep uses mutex. Is to use however condvare not better ?
===============================
Javier Miranda explains in "A Detailed Description of the GNU Ada Run Time"
why gnat uses condvare and not mutex 
for the synchronisation of threads.

Low-Level Locks 

The GNAT run-time uses Lock/Unlock operations in order to maintain data
consistency under concurrent 
read/update operations by multiple threads of control. 
.................
Mutual exclusion is provided through POSIX mutexes. When a thread wants
exclusive access to some shared resource, 
it locks the associated mutex, via pthread_mutex_lock(); if some other
thread has already locked that mutex, 
the requesting thread is suspended until the thread holding the mutex
unlocks it, via pthread_mutex_unlock(). 
Any number of tasks can be suspended on the same mutex; one of them is
granted the mutex and permitted to continue 
execution when the holder unlocks the mutex. Mutexes are similar to binary
semaphores; the principal difference 
is that the thread which holds the mutex must be the one to unlock it. This
makes mutexes difficult to use for 
general communication between threads; an arbitrary thread cannot signal to
other threads that something has 
occurred by unlocking a locked mutex. For this kind of synchronization,
condition variables are used. 

A thread waits for a condition to become true by calling pthread_cond_wait()
on a condition variable. 
Another thread can signal that the condition has become true by signaling
the condition variable, via 
pthread_cond_signal() (this is not to be confused with operations on POSIX
signals). A mutex is associated with 
the condition variable by the pthread_cond_wait() call. This mutex must be
locked before the call; 
it is unlocked (atomically) by the call and locked again before the call
returns. This is to protect the 
condition for which the thread is waiting. A pthread_cond_signal() call is
guaranteed to wake up at least one 
waiting thread, but it turns out to be more efficient (particularly on
multiprocessors) to allow more than one 
waiting thread to return. Since the first thread to reacquire the associated
mutex might make the condition false 
again, each thread needs to check that the condition is true when
pthread_cond_wait() returns. 
This is usually done in a while loop.


-- 
View this message in context: 
http://old.nabble.com/QNX---GNUstep-and-Objective-C-tp26047107p26148884.html
Sent from the GNUstep - General mailing list archive at Nabble.com.