Groups | Search | Server Info | Login | Register

Groups > comp.os.vms > #378356

Re: more CMA

Show all headers | View raw

In article <10h807g$hm6v$2@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:
>On 12/8/2025 3:55 PM, Dan Cross wrote:
>> In article <69345887$0$663$14726298@news.sunsite.dk>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> There are something in cma not present in pthread.
>>>
>>> The cma API comes with the cma_lib_queue_* functions.
>> 
>> Presumably this doesn't exist in pthreads because it's simple to
>> do oneself using the tools that interface gives you (mutexes and
>> condition variables, specifically).
>
>It is almost always possible to go DIY.
>
>But why? If someone else is willing to do it, then it is great!

Because by doing so, one conflates mechanism and policy, and one
runs the risk of choosing the existing policy implementation in
places where it's really not appropriate, simply because that's
what's already there.

>> Nothing in the CMA lib APIs strikes me as particularly worth
>> adding it to the interface, and one can imagine all sorts of
>> enhancements that it just doesn't provide (prioritization;
>> fairness; sending by value instead of reference, etc).
>
>Don't let perfect be the enemy of good.

Sure.  But the hard part of software engineering is finding the
right balance between adopting canned solutions to common
problems juxtaposted with forcing a particular design "shape"
onto programs.

Threads are a basic building block for concurrent programs; they
are mechanism, and as such, it makes sense to provide some
primitive exposing them, particularly on systems where a thread
is an OS-managed object.  On the other hand, the specific
implementation of queues is a lot closer to policy, for the
aforementioned reasons (a queue for a particular application may
want to take into account priority of queued items, or fairness
and hysteresis with respect to scheduling produces and
consumers, etc).  Thus, it makes less sense to provide them as a
library abstraction.

>>> Doing similar to java.util.concurrent.BlockingQueue
>>> if you are familiar with that.
>> 
>> Well, not quite.  That's generic over some element type, E.  The
>> CMA library functions, and my own trivial example, just use a
>> pointer, which is rather different.
>
>The Java version is more type safe than the C version.
>
>But I think that matches the preference of both Java and C
>people.

Generics gove a measure od type safety not managable in C.

	- Dan C.

Back to comp.os.vms | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-03 21:21 -0500
  Re: more CMA kludge@panix.com (Scott Dorsey) - 2025-12-03 21:38 -0500
    Re: more CMA Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-04 13:40 +0000
  Re: more CMA Roy Omond <roy@omond.net> - 2025-12-04 12:04 +0000
    Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 09:23 -0500
      Re: more CMA Volker Halle <volker_halle@hotmail.com> - 2025-12-04 16:48 +0100
        Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 11:55 -0500
      Re: more CMA Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-04 18:29 +0000
        Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 14:12 -0500
          Re: more CMA Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-04 19:49 +0000
            Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 15:59 -0500
              Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-06 11:23 -0500
                Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-08 20:55 +0000
                Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-08 21:06 -0500
                Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-09 04:46 +0000
          Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 16:55 -0500
            Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-05 17:15 +0000
              Re: more CMA Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-05 18:06 +0000
                Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-08 12:33 +0000
              Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-05 18:39 -0500
                Re: more CMA cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-08 14:14 +0000
      Re: more CMA hb0815 <mw40171@mucweb.de> - 2025-12-05 21:52 +0100
        Re: more CMA Arne Vajhøj <arne@vajhoej.dk> - 2025-12-05 18:21 -0500

csiph-web