[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QNX - GNUstep and Objective C
From: |
bbceler |
Subject: |
Re: QNX - GNUstep and Objective C |
Date: |
Sun, 1 Nov 2009 03:25:23 -0800 (PST) |
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.
- Re: QNX - GNUstep and Objective C,
bbceler <=