Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #103868

Re: Memory not updating in thread as expected

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c
Subject Re: Memory not updating in thread as expected
Date 2017-02-14 12:46 +0100
Organization A noiseless patient Spider
Message-ID <o7uqj2$vn$1@dont-email.me> (permalink)
References (2 earlier) <ggg3acdd9s4h3p47f4488mns89opglousv@4ax.com> <o7tb2c$40o$1@dont-email.me> <o7ts13$d40$1@dont-email.me> <o7ufui$upl$1@dont-email.me> <87lgt9rpww.fsf@bsb.me.uk>

Show all headers | View raw


On 14/02/17 12:07, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <snip>
> 
>> To be honest, I am far from convinced that the C11 threading stuff is
>> useful.  The atomics can be useful (though hard to understand), but
>> threading is too specific to the OS in question - an abstraction like
>> <threads.h> is not a good match.  For Linux, you want support for
>> standard mutexes, fast mutexes, spinlocks, read-write locks, etc. - a
>> library that gives you only simple condition variables and mutexes is
>> not enough.
> 
> I would defer to your experience in this matter were it not for the fact
> that I've heard this argument so many times over the decades.  We can't
> just have loops and tests and function calls, we need computed gotos,
> alternate returns and coroutines.  C's standard IO is just too crude, we
> need access to the OS's record-oriented IO or what have you.
> 

I just read Alain's post about using the mtx_ and cnd_ functions to
handle the synchronisation.  If you have semaphores, the solution is:

// Before splitting the threads
sem_t sem;
sem_init(&sem, 0, 0);

// thread 1
work1();
sem_post(&sem);

// thread 2
sem_wait(&sem);
work2();


It is much simpler and clearer, and does not need extra flag variables.

Now, the <thread.h> functions are enough to implement semaphores.  So in
that sense, they give a solid base.  But I have to wonder - who would
use them?  Why would someone use the C11 threading functions when their
OS already provides more powerful and more convenient features?  Why
would they use the new, limited functions rather than the well-known
ones with countless examples and tutorials a quick google away?

You could argue for portability - that it lets you write platform
independent multi-threaded code in C.  But you can already do that -
just use existing libraries for the purpose.  What benefits are there in
making a semaphore structure that uses the C11 thread features, as
compared to using a semaphore structure that is a wrapper around, say,
Posix and Windows semaphores?  (I can tell you without doubt that no one
will use them for things like embedded RTOS systems.)


> Don't get me wrong -- there will always be some cases where such an
> argument is valid, and these arguments all had merit at the time due to
> practical considerations, programmer experience and so on, but, in the
> long run, programming has improved by offering having fewer, simpler and
> more general abstractions.

I agree on that, in principle.  But the C11 abstractions for threading
are too few, too simple, and do not match well to real-world usage.  C11
(and C++11) threading sounds like a nice idea, but seems to me to be too
little, too late.

However, I would be quite happy to be proven wrong!

> 
> The real solution is probably even higher-level abstractions at the
> language level, but that's not an option for C in that C's niche will
> always be a low-end of the abstraction spectrum.  So it seems at least
> possible that C's threading and synchronisation mechanisms might become
> the stdio.h of concurrency (in a decade or two).
> 
> The low-level mechanisms are a mess right now.  Alain Ketterlin
> helpfully posted an example, but there a few things he was not sure
> about.  Must the signal call be protected by the mutex, and could the
> 'while' used in waiting be an 'if' in this case?[1]  It all seems a bit
> like the modern version of "can you jump over a declaration?".
> 
> [1] I don't want to sound curmudgeonly -- that poster was braver than I.
> I considered offering an example but then thought about all the details
> I'd have to check up on and how likely I would be to make a mess of it.
> He clearly knows his stuff.  In fact, I think that asking when, and on
> what systems, can you use 'if' like that with a condition variable would
> make a good interview question!
> 

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Memory not updating in thread as expected Test <test@.nil.invalid.com> - 2017-02-13 12:46 +0200
  Re: Memory not updating in thread as expected m.labanowicz@gmail.com - 2017-02-13 05:18 -0800
    Re: Memory not updating in thread as expected Test <test@.nil.invalid.com> - 2017-02-13 16:25 +0200
      Re: Memory not updating in thread as expected m.labanowicz@gmail.com - 2017-02-13 10:30 -0800
        Re: Memory not updating in thread as expected Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-13 14:30 -0500
  Re: Memory not updating in thread as expected m.labanowicz@gmail.com - 2017-02-13 05:46 -0800
    Re: Memory not updating in thread as expected Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-13 14:30 +0000
      Re: Memory not updating in thread as expected "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-02-13 15:13 -0800
    Re: Memory not updating in thread as expected Test <test@.nil.invalid.com> - 2017-02-13 16:36 +0200
      Re: Memory not updating in thread as expected David Brown <david.brown@hesbynett.no> - 2017-02-13 23:15 +0100
        Re: Memory not updating in thread as expected James Kuyper <jameskuyper@verizon.net> - 2017-02-13 22:04 -0500
          Re: Memory not updating in thread as expected David Brown <david.brown@hesbynett.no> - 2017-02-14 09:44 +0100
            Re: Memory not updating in thread as expected Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-14 11:07 +0000
              Re: Memory not updating in thread as expected David Brown <david.brown@hesbynett.no> - 2017-02-14 12:46 +0100
                Re: Memory not updating in thread as expected Robert Wessel <robertwessel2@yahoo.com> - 2017-02-16 05:12 -0600
                Re: Memory not updating in thread as expected David Brown <david.brown@hesbynett.no> - 2017-02-16 12:44 +0100
              Re: Memory not updating in thread as expected Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2017-02-14 15:53 +0100
                Re: Memory not updating in thread as expected Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-14 15:36 +0000
                Re: Memory not updating in thread as expected Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2017-02-14 17:58 +0100
                Re: Memory not updating in thread as expected Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-14 17:26 +0000
          Re: Memory not updating in thread as expected Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2017-02-14 10:43 +0100
            Re: Memory not updating in thread as expected Robert Wessel <robertwessel2@yahoo.com> - 2017-02-14 03:52 -0600
              Re: Memory not updating in thread as expected Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2017-02-14 11:36 +0100
              Re: Memory not updating in thread as expected supercat@casperkitty.com - 2017-02-14 05:31 -0800
  Re: Memory not updating in thread as expected Ken Brody <kenbrody@spamcop.net> - 2017-02-13 12:44 -0500
  Re: Memory not updating in thread as expected Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-13 10:58 -0700
  Re: Memory not updating in thread as expected "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-02-14 15:13 -0800
    Re: Memory not updating in thread as expected "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-02-14 16:37 -0800

csiph-web