subject:"\[PATCH\] score\: Unify CORE mutex seize\/surrender"

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Chris Johns


On 28/09/2016 18:38, Pavel Pisa wrote:

And even rtems_* API should include mutex operations.
It is clear and it is not necessary to complicate
documentation then what is allowed and what is not
with each semaphore flags combination.


I am fine with adding a mutex API to the Classic API. The current mutex 
interface would need to be kept for a release or two before we could 
remove it if it ever is.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Pavel Pisa

Hello Sebastian,

On Wednesday 28 of September 2016 11:06:19 Sebastian Huber wrote:
> On 28/09/16 10:47, Sebastian Huber wrote:
> > On 28/09/16 10:38, Pavel Pisa wrote:
> >> Hello Sebastian and Gedare,
> >>
> >> I cannot hold myself to not express my opinion there.
> >>
> >> On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:
> >>> On 27/09/16 16:59, Gedare Bloom wrote:
>  A mostly unrelated question: why do we have two different
>  _Semaphore_Get functions, one static in score/src/semaphore.c and the
>  other inlined from semimpl.h?
> >>>
> >>> Yes, this is a bit confusing. One is part of the Classic API, the other
> >>> is for the self-contained semaphores.
> >>
> >> what is the reason to name these self-contained semaphores.
> >
> > the name "self-contained" is used for objects which work with a user
> > supplied storage.  For example:
> >
> > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib
> >/libc/sys/rtems/include/sys/lock.h;h=c261adf681e542af945969149f6533248eb06
> >fd6;hb=HEAD
> >
> >
> > In contrast to the Classic and POSIX objects which work with a kernel
> > supplied storage which is accessed via the object identifier.
> >
> > In the context of the Newlib  a "semaphore" is a counting
> > semaphore.
>
> In case the name "self-contained" is confusing for this purpose, then I
> am happy to replace it with a better alternative.

No, I like self-contained, I have no problem with that. It describes
how it works. I have problem with SEMPAHORE part because
it associates for me with IPC/inter thread even delivery, producer
consumer pattern. Not mutual exclusion of enter to given code.

Excuse for confussing specification of the naming note.

Best wishes,

 Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Sebastian Huber

On 28/09/16 10:47, Sebastian Huber wrote:

On 28/09/16 10:38, Pavel Pisa wrote:

Hello Sebastian and Gedare,

I cannot hold myself to not express my opinion there.

On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:

On 27/09/16 16:59, Gedare Bloom wrote:

A mostly unrelated question: why do we have two different
_Semaphore_Get functions, one static in score/src/semaphore.c and the
other inlined from semimpl.h?

Yes, this is a bit confusing. One is part of the Classic API, the other
is for the self-contained semaphores.

what is the reason to name these self-contained semaphores.

the name "self-contained" is used for objects which work with a user
supplied storage. For example:

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/lock.h;h=c261adf681e542af945969149f6533248eb06fd6;hb=HEAD

In contrast to the Classic and POSIX objects which work with a kernel
supplied storage which is accessed via the object identifier.

In the context of the Newlib a "semaphore" is a counting
semaphore.

In case the name "self-contained" is confusing for this purpose, then I
am happy to replace it with a better alternative.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Sebastian Huber


On 28/09/16 10:38, Pavel Pisa wrote:

Hello Sebastian and Gedare,

I cannot hold myself to not express my opinion there.

On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:

On 27/09/16 16:59, Gedare Bloom wrote:

A mostly unrelated question: why do we have two different
_Semaphore_Get functions, one static in score/src/semaphore.c and the
other inlined from semimpl.h?

Yes, this is a bit confusing. One is part of the Classic API, the other
is for the self-contained semaphores.

what is the reason to name these self-contained semaphores.


the name "self-contained" is used for objects which work with a user 
supplied storage.  For example:


https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/lock.h;h=c261adf681e542af945969149f6533248eb06fd6;hb=HEAD

In contrast to the Classic and POSIX objects which work with a kernel 
supplied storage which is accessed via the object identifier.


In the context of the Newlib  a "semaphore" is a counting 
semaphore.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Pavel Pisa

Hello Sebastian and Gedare,

I cannot hold myself to not express my opinion there.

On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:
> On 27/09/16 16:59, Gedare Bloom wrote:
> > A mostly unrelated question: why do we have two different
> > _Semaphore_Get functions, one static in score/src/semaphore.c and the
> > other inlined from semimpl.h?
>
> Yes, this is a bit confusing. One is part of the Classic API, the other
> is for the self-contained semaphores.

what is the reason to name these self-contained semaphores.
If they cannot be used as signaling mechanism between threads,
then they should be called mutexes to clearly state,
that the only valid use is initialize it as full,
gain and release it from the same thread.

For me, even use of simple, full binary etc.. semaphores
in the classic RTEMS API is a problem. There is semaphore
and mutex and each has different semantic and rules.

I understand, that historically semaphore has more meaning
as the way to pass only one task or limited number of tasks
to given part of the road, but today meaning is settled.

So if the self-contained x cannot be used to signal event
between threads then it is mutex. If there is plan to
use self-contained x even like futex/conditional variable
etc., then situation is more complex and it has reason
to have some naming layer working with semaphore or futex
stem but programmer should get clear mutex named primitives
at the end. Which is what POSIX does. Linux kernel internal
APIs cured this confusion some time ago as well.

And even rtems_* API should include mutex operations.
It is clear and it is not necessary to complicate
documentation then what is allowed and what is not
with each semaphore flags combination.

Best wishes,

  Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-27 Thread Sebastian Huber


On 27/09/16 16:59, Gedare Bloom wrote:

A mostly unrelated question: why do we have two different
_Semaphore_Get functions, one static in score/src/semaphore.c and the
other inlined from semimpl.h?


Yes, this is a bit confusing. One is part of the Classic API, the other 
is for the self-contained semaphores.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-27 Thread Gedare Bloom

OK. A mostly unrelated question: why do we have two different
_Semaphore_Get functions, one static in score/src/semaphore.c and the
other inlined from semimpl.h?

On Tue, Sep 27, 2016 at 9:25 AM, Sebastian Huber
 wrote:
> Use the Thread_Control::resource_count for the no protocol mutexes.
> Merge the no protocol and priority inherit CORE mutex seize/surrender
> operations.
> ---
>  cpukit/libnetworking/rtems/rtems_glue.c  |  2 +
>  cpukit/posix/src/mutexlocksupp.c |  3 +-
>  cpukit/posix/src/mutexunlock.c   |  3 +-
>  cpukit/rtems/src/semobtain.c |  3 +-
>  cpukit/rtems/src/semrelease.c|  4 +-
>  cpukit/score/include/rtems/score/coremuteximpl.h | 93 
> ++--
>  cpukit/score/src/apimutexlock.c  |  1 +
>  cpukit/score/src/apimutexunlock.c|  1 +
>  8 files changed, 18 insertions(+), 92 deletions(-)
>
> diff --git a/cpukit/libnetworking/rtems/rtems_glue.c 
> b/cpukit/libnetworking/rtems/rtems_glue.c
> index 9a7f82f..46f8765 100644
> --- a/cpukit/libnetworking/rtems/rtems_glue.c
> +++ b/cpukit/libnetworking/rtems/rtems_glue.c
> @@ -379,6 +379,7 @@ rtems_bsdnet_semaphore_obtain (void)
> _Thread_queue_Context_set_no_timeout( _context );
> status = _CORE_recursive_mutex_Seize (
> _networkSemaphore->Core_control.Mutex.Recursive,
> +   CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
> _Thread_Executing,
> true,   /* wait */
> _CORE_recursive_mutex_Seize_nested,
> @@ -412,6 +413,7 @@ rtems_bsdnet_semaphore_release (void)
> _ISR_lock_ISR_disable(_context.Lock_context.Lock_context);
> status = _CORE_recursive_mutex_Surrender(
> _networkSemaphore->Core_control.Mutex.Recursive,
> +   CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
> _Thread_Executing,
> _context
> );
> diff --git a/cpukit/posix/src/mutexlocksupp.c 
> b/cpukit/posix/src/mutexlocksupp.c
> index 1da6238..ea4c4e3 100644
> --- a/cpukit/posix/src/mutexlocksupp.c
> +++ b/cpukit/posix/src/mutexlocksupp.c
> @@ -76,7 +76,7 @@ int _POSIX_Mutex_Lock_support(
>);
>break;
>  case POSIX_MUTEX_NO_PROTOCOL:
> -  status = _CORE_recursive_mutex_Seize_no_protocol(
> +  status = _CORE_recursive_mutex_Seize(
>  _mutex->Mutex.Recursive,
>  POSIX_MUTEX_NO_PROTOCOL_TQ_OPERATIONS,
>  executing,
> @@ -89,6 +89,7 @@ int _POSIX_Mutex_Lock_support(
>_Assert( the_mutex->protocol == POSIX_MUTEX_PRIORITY_INHERIT );
>status = _CORE_recursive_mutex_Seize(
>  _mutex->Mutex.Recursive,
> +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
>  executing,
>  wait,
>  _POSIX_Mutex_Lock_nested,
> diff --git a/cpukit/posix/src/mutexunlock.c b/cpukit/posix/src/mutexunlock.c
> index 3144314..c15f7e6 100644
> --- a/cpukit/posix/src/mutexunlock.c
> +++ b/cpukit/posix/src/mutexunlock.c
> @@ -53,7 +53,7 @@ int pthread_mutex_unlock(
>);
>break;
>  case POSIX_MUTEX_NO_PROTOCOL:
> -  status = _CORE_recursive_mutex_Surrender_no_protocol(
> +  status = _CORE_recursive_mutex_Surrender(
>  _mutex->Mutex.Recursive,
>  POSIX_MUTEX_NO_PROTOCOL_TQ_OPERATIONS,
>  executing,
> @@ -64,6 +64,7 @@ int pthread_mutex_unlock(
>_Assert( the_mutex->protocol == POSIX_MUTEX_PRIORITY_INHERIT );
>status = _CORE_recursive_mutex_Surrender(
>  _mutex->Mutex.Recursive,
> +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
>  executing,
>  _context
>);
> diff --git a/cpukit/rtems/src/semobtain.c b/cpukit/rtems/src/semobtain.c
> index 9afef54..b81612e 100644
> --- a/cpukit/rtems/src/semobtain.c
> +++ b/cpukit/rtems/src/semobtain.c
> @@ -75,6 +75,7 @@ rtems_status_code rtems_semaphore_obtain(
>  case SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY:
>status = _CORE_recursive_mutex_Seize(
>  _semaphore->Core_control.Mutex.Recursive,
> +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
>  executing,
>  wait,
>  _CORE_recursive_mutex_Seize_nested,
> @@ -91,7 +92,7 @@ rtems_status_code rtems_semaphore_obtain(
>);
>break;
>  case SEMAPHORE_VARIANT_MUTEX_NO_PROTOCOL:
> -  status = _CORE_recursive_mutex_Seize_no_protocol(
> +  status = _CORE_recursive_mutex_Seize(
>  _semaphore->Core_control.Mutex.Recursive,
>  _Semaphore_Get_operations( the_semaphore ),
>  executing,
> diff --git a/cpukit/rtems/src/semrelease.c b/cpukit/rtems/src/semrelease.c
> index 39c467d..40860a1 100644
> --- a/cpukit/rtems/src/semrelease.c
> +++ b/cpukit/rtems/src/semrelease.c
> @@ -52,6 +52,7 @@ rtems_status_code rtems_semaphore_release( rtems_id id )
>  case SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY:
>status =

[PATCH] score: Unify CORE mutex seize/surrender

2016-09-27 Thread Sebastian Huber

Use the Thread_Control::resource_count for the no protocol mutexes.
Merge the no protocol and priority inherit CORE mutex seize/surrender
operations.
---
 cpukit/libnetworking/rtems/rtems_glue.c  |  2 +
 cpukit/posix/src/mutexlocksupp.c |  3 +-
 cpukit/posix/src/mutexunlock.c   |  3 +-
 cpukit/rtems/src/semobtain.c |  3 +-
 cpukit/rtems/src/semrelease.c|  4 +-
 cpukit/score/include/rtems/score/coremuteximpl.h | 93 ++--
 cpukit/score/src/apimutexlock.c  |  1 +
 cpukit/score/src/apimutexunlock.c|  1 +
 8 files changed, 18 insertions(+), 92 deletions(-)

diff --git a/cpukit/libnetworking/rtems/rtems_glue.c 
b/cpukit/libnetworking/rtems/rtems_glue.c
index 9a7f82f..46f8765 100644
--- a/cpukit/libnetworking/rtems/rtems_glue.c
+++ b/cpukit/libnetworking/rtems/rtems_glue.c
@@ -379,6 +379,7 @@ rtems_bsdnet_semaphore_obtain (void)
_Thread_queue_Context_set_no_timeout( _context );
status = _CORE_recursive_mutex_Seize (
_networkSemaphore->Core_control.Mutex.Recursive,
+   CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
_Thread_Executing,
true,   /* wait */
_CORE_recursive_mutex_Seize_nested,
@@ -412,6 +413,7 @@ rtems_bsdnet_semaphore_release (void)
_ISR_lock_ISR_disable(_context.Lock_context.Lock_context);
status = _CORE_recursive_mutex_Surrender(
_networkSemaphore->Core_control.Mutex.Recursive,
+   CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
_Thread_Executing,
_context
);
diff --git a/cpukit/posix/src/mutexlocksupp.c b/cpukit/posix/src/mutexlocksupp.c
index 1da6238..ea4c4e3 100644
--- a/cpukit/posix/src/mutexlocksupp.c
+++ b/cpukit/posix/src/mutexlocksupp.c
@@ -76,7 +76,7 @@ int _POSIX_Mutex_Lock_support(
   );
   break;
 case POSIX_MUTEX_NO_PROTOCOL:
-  status = _CORE_recursive_mutex_Seize_no_protocol(
+  status = _CORE_recursive_mutex_Seize(
 _mutex->Mutex.Recursive,
 POSIX_MUTEX_NO_PROTOCOL_TQ_OPERATIONS,
 executing,
@@ -89,6 +89,7 @@ int _POSIX_Mutex_Lock_support(
   _Assert( the_mutex->protocol == POSIX_MUTEX_PRIORITY_INHERIT );
   status = _CORE_recursive_mutex_Seize(
 _mutex->Mutex.Recursive,
+CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
 executing,
 wait,
 _POSIX_Mutex_Lock_nested,
diff --git a/cpukit/posix/src/mutexunlock.c b/cpukit/posix/src/mutexunlock.c
index 3144314..c15f7e6 100644
--- a/cpukit/posix/src/mutexunlock.c
+++ b/cpukit/posix/src/mutexunlock.c
@@ -53,7 +53,7 @@ int pthread_mutex_unlock(
   );
   break;
 case POSIX_MUTEX_NO_PROTOCOL:
-  status = _CORE_recursive_mutex_Surrender_no_protocol(
+  status = _CORE_recursive_mutex_Surrender(
 _mutex->Mutex.Recursive,
 POSIX_MUTEX_NO_PROTOCOL_TQ_OPERATIONS,
 executing,
@@ -64,6 +64,7 @@ int pthread_mutex_unlock(
   _Assert( the_mutex->protocol == POSIX_MUTEX_PRIORITY_INHERIT );
   status = _CORE_recursive_mutex_Surrender(
 _mutex->Mutex.Recursive,
+CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
 executing,
 _context
   );
diff --git a/cpukit/rtems/src/semobtain.c b/cpukit/rtems/src/semobtain.c
index 9afef54..b81612e 100644
--- a/cpukit/rtems/src/semobtain.c
+++ b/cpukit/rtems/src/semobtain.c
@@ -75,6 +75,7 @@ rtems_status_code rtems_semaphore_obtain(
 case SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY:
   status = _CORE_recursive_mutex_Seize(
 _semaphore->Core_control.Mutex.Recursive,
+CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
 executing,
 wait,
 _CORE_recursive_mutex_Seize_nested,
@@ -91,7 +92,7 @@ rtems_status_code rtems_semaphore_obtain(
   );
   break;
 case SEMAPHORE_VARIANT_MUTEX_NO_PROTOCOL:
-  status = _CORE_recursive_mutex_Seize_no_protocol(
+  status = _CORE_recursive_mutex_Seize(
 _semaphore->Core_control.Mutex.Recursive,
 _Semaphore_Get_operations( the_semaphore ),
 executing,
diff --git a/cpukit/rtems/src/semrelease.c b/cpukit/rtems/src/semrelease.c
index 39c467d..40860a1 100644
--- a/cpukit/rtems/src/semrelease.c
+++ b/cpukit/rtems/src/semrelease.c
@@ -52,6 +52,7 @@ rtems_status_code rtems_semaphore_release( rtems_id id )
 case SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY:
   status = _CORE_recursive_mutex_Surrender(
 _semaphore->Core_control.Mutex.Recursive,
+CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
 executing,
 _context
   );
@@ -64,13 +65,12 @@ rtems_status_code rtems_semaphore_release( rtems_id id )
   );
   break;
 case SEMAPHORE_VARIANT_MUTEX_NO_PROTOCOL:
-  _CORE_recursive_mutex_Surrender_no_protocol(
+  status = _CORE_recursive_mutex_Surrender(
 _semaphore->Core_control.Mutex.Recursive,

Re: [PATCH] score: Unify CORE mutex seize/surrender

Re: [PATCH] score: Unify CORE mutex seize/surrender

Re: [PATCH] score: Unify CORE mutex seize/surrender

Re: [PATCH] score: Unify CORE mutex seize/surrender

Re: [PATCH] score: Unify CORE mutex seize/surrender

Re: [PATCH] score: Unify CORE mutex seize/surrender

Re: [PATCH] score: Unify CORE mutex seize/surrender

[PATCH] score: Unify CORE mutex seize/surrender

8 matches

Site Navigation

Mail list logo

Footer information