Re: [DNG] Wirth's law

[Didier Kryn]

Le 27/07/2016 17:54, Rainer Weikusat a écrit :

- resent after someone made Spamhaus remove the @talktalk.net e-mail
   blacklisting entry -


Didier Kryn  writes:

Le 26/07/2016 12:59, Rainer Weikusat a écrit :

Didier Kryn  writes:

Le 25/07/2016 01:29, Rainer Weikusat a écrit :

Sleeping on a contended mutex is implemented in this way. But that's
supposed to be an exceptional case.

  This is why, while advertizing itself as a cool "don't care"
feature, a mutex is problematic:

I don't know who's advertising that "don't care" use of shared variables
would be "cool" and who's being targetted by this advertising (and I
don't even want to know) but I don't share this opinion. This applies
equally to single-threaded and multi-threaded applications. A mutex is a
synchronisation primitive useful for implementing userspace inter-thread
communication facilities (this is a bit too general).

 This bias of mine comes from the fact that, in high level
languages, mutexes are embedded inside dedicated objects, and the
application can assign values to these objects exactly as it would do
for any other object (without specific care).

This could refer to Java 'synchronized things'. But these provide some
kind of high-level synchronization object called 'a monitor' and
'mutexes' (mutual exclusion locks) are just a primitive necessary for
implementing one. And the "use just like the global variables you'd
otherwise use" seems to suggest a programming style you seem to consider
more universal than I do.

Assuming I filled in the blanks halfway correctly, that's still a
certain style of programming which is already not a terribly good idea
for a single-threaded application. Using it in a multi-threaded one
'multi-threads' the inherent problems. This would be an example how one
can utilize the potential of more 'modern' technical (shared memory
multi-processors aka 'multicore CPUs') to achieve the same effect
(create a total chaos) much faster :->.

[...]




Never have written a single line of Java. It takes me a strong 
motivation to start learning another language.


Mutex-protected objects can be built in C++, and are part of the 
Ada language. It is difficult to decide what Ada should do in this case; 
I don't know if the issue has been discussed but this kind of object 
looks to me like a difficult compromise.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Arnt Gulbrandsen]

Rainer Weikusat writes:

This can be avoided by ensuring that each thread which needs to hold A
and B acquired A first and B second.


Every time I've run into that in the past ten years, the reason for the 
deadlock was that subsystem X locked B and subsystem Y Z, and then someone 
made a function in X call one in Y.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Rainer Weikusat]

- resent after someone made Spamhaus remove the @talktalk.net e-mail
  blacklisting entry -


Didier Kryn  writes:
> Le 26/07/2016 12:59, Rainer Weikusat a écrit :
>> Didier Kryn  writes:
>>> Le 25/07/2016 01:29, Rainer Weikusat a écrit :
 Sleeping on a contended mutex is implemented in this way. But that's
 supposed to be an exceptional case.
>>>  This is why, while advertizing itself as a cool "don't care"
>>> feature, a mutex is problematic:
>> I don't know who's advertising that "don't care" use of shared variables
>> would be "cool" and who's being targetted by this advertising (and I
>> don't even want to know) but I don't share this opinion. This applies
>> equally to single-threaded and multi-threaded applications. A mutex is a
>> synchronisation primitive useful for implementing userspace inter-thread
>> communication facilities (this is a bit too general).
>
> This bias of mine comes from the fact that, in high level
> languages, mutexes are embedded inside dedicated objects, and the
> application can assign values to these objects exactly as it would do
> for any other object (without specific care).

This could refer to Java 'synchronized things'. But these provide some
kind of high-level synchronization object called 'a monitor' and
'mutexes' (mutual exclusion locks) are just a primitive necessary for
implementing one. And the "use just like the global variables you'd
otherwise use" seems to suggest a programming style you seem to consider
more universal than I do.

Assuming I filled in the blanks halfway correctly, that's still a
certain style of programming which is already not a terribly good idea
for a single-threaded application. Using it in a multi-threaded one
'multi-threads' the inherent problems. This would be an example how one
can utilize the potential of more 'modern' technical (shared memory
multi-processors aka 'multicore CPUs') to achieve the same effect
(create a total chaos) much faster :->.

[...]

>>   In case it [hold more than one lock] is, care
>> must be taken to ensure that they always try to acquire all members of
>> the shared set of mutexes in the same order to avoid deadlocks.
>>
> All threads aquiring locks in the same order, this is equivalent
> to having only one lock, no?

A so-called deadlock occurs if one thread of execution holds a lock A
and tries to acquire another lock B while some other thread tries to
acquire A while holding B. This means thread #1 blocks until thread #2
releases B and thread #2 blocks until thread #1 release A. Since they're
now both blocked, none of them will ever release anything.

This can be avoided by ensuring that each thread which needs to hold A
and B acquired A first and B second.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Hendrik Boom]

On Wed, Jul 27, 2016 at 08:15:27AM +0200, Didier Kryn wrote:
> Le 26/07/2016 12:59, Rainer Weikusat a écrit :
> >Didier Kryn  writes:
> >>Le 25/07/2016 01:29, Rainer Weikusat a écrit :
> >>>Sleeping on a contended mutex is implemented in this way. But that's
> >>>supposed to be an exceptional case.
> >> This is why, while advertizing itself as a cool "don't care"
> >>feature, a mutex is problematic:
> >I don't know who's advertising that "don't care" use of shared variables
> >would be "cool" and who's being targetted by this advertising (and I
> >don't even want to know) but I don't share this opinion. This applies
> >equally to single-threaded and multi-threaded applications. A mutex is a
> >synchronisation primitive useful for implementing userspace inter-thread
> >communication facilities (this is a bit too general).
> >
> 
> This bias of mine comes from the fact that, in high level languages,
> mutexes are embedded inside dedicated objects, and the application can
> assign values to these objects exactly as it would do for any other object
> (without specific care).
> 
> I absolutely expected you wouldn't share my opinion :->
> 
> >>the programmer should make sure contention is exceptional and there is
> >>no risk of dead-lock.
> >Mutexes (or any other kind of lock) should usually be uncontended if
> >performance is considered important. It's often not necessary that
> >threads hold more than one mutex at the same time.
> 
> Here we see that we probably think of very different uses cases.
> 
> >  In case it is, care
> >must be taken to ensure that they always try to acquire all members of
> >the shared set of mutexes in the same order to avoid deadlocks.
> >
> 
> All threads aquiring locks in the same order, this is equivalent to
> having only one lock, no?

No.

The requirement isn't that a thread acquire all the locks.  It's 
that there be an ordering of locks so that if a thread acquires locks E, F, 
G in that order, then  E > F > G by the global order. There's no 
requirement that some other thread can't acquire G without acquiring E 
or F at all.  What it can't do is acquire E or F after acquiring G.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Adam Borowski]

On Tue, Jul 26, 2016 at 12:07:31PM +0100, Rainer Weikusat wrote:
> I think you meant to write coroutines, not closures, as that's what go
> adopted based on Hoare's 'Communicating Sequential Processes'. That's
> also pretty 'old stuff'. It's also unfortunately an instace of something
> which should really be called such-and-such-a-law,
> 
>   As soon as one guy has learnt that people use multi-threading to exploit
> shared-memory multi-processors and not to avoid state machines, on 
> comes
>   the next "been living under a rock since 197x" person and re-implements
>   cooperative userspace threading again.

Coroutines _are_ a nice thing that simplifies producer/consumer code and a
bunch of other schemes, but they are stuck within a single thread.  As
interthread/interprocess synchronization is costly, this is often the right
thing to do.

But, these days, any software that actually needs processing power (rather
than merely wasting it because of being written in Visual Basic or PHP, or
without understanding how to code) will need multiple threads/processes.
The Moore's law for single threaded computation is dead.  At 4GHz, light can
travel just 8cm per clock cycle, there's only so much we can do to improve
performance.  Tricks like pipelines, speculative execution, etc, has been
mostly exhausted within the last decade, and we quite hit a wall.  It'd take
a completely new paradigm to get us a significant improvement, and even
that'd bring no more than a single order of magnitude more speed.  Perhaps
two orders with extreme nanotechnology of the future.

So, we're at the end of the road of current style of processors, and not
that far from the end with speculative future technology with anything that
resembles classical processors.  Thus, sorry, there's no way around
multithreading.


-- 
An imaginary friend squared is a real enemy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Rainer Weikusat]

Jaromil  writes:
> On Sun, 24 Jul 2016, Rainer Weikusat wrote:
>> Didier Kryn  writes:
>> > Le 22/07/2016 18:21, Brian Nash a écrit :
>> >> For example, when I discovered multithreading, all my programs used it
>> >> in some way, even when it was unnecessary. 
>> >
>> > I sometimes use multithreading, but never mutexes. Mutex can be
>> > harmless if there's only one. Otherwise better use select()/poll() or
>> > you'll waste time or even dead-lock. It's amazing how the old select()
>> > paradigm is so much better than the modern mutex. I see mutex as an
>> > invention to relieve the programmer from thinking.
>> 
>> One of the advantages of having more than one thread of execution
>> running in the same address space is that these can communicate with
>> each other without going through the kernel. And 'a mutex' is just a
>> basic primitive for implementing this.
>
> nowadays the closures paradigm (basically fifo pipes of pointers to
> stateless functions) is used much more than all that mutex and
> semaphore old stuff.
>
> i.e. golang adopted closures since the beginning
> with great success.

I think you meant to write coroutines, not closures, as that's what go
adopted based on Hoare's 'Communicating Sequential Processes'. That's
also pretty 'old stuff'. It's also unfortunately an instace of something
which should really be called such-and-such-a-law,

As soon as one guy has learnt that people use multi-threading to exploit
shared-memory multi-processors and not to avoid state machines, on comes
the next "been living under a rock since 197x" person and re-implements
cooperative userspace threading again.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Rainer Weikusat]

Didier Kryn  writes:
> Le 25/07/2016 01:29, Rainer Weikusat a écrit :
>> Sleeping on a contended mutex is implemented in this way. But that's
>> supposed to be an exceptional case.
>
> This is why, while advertizing itself as a cool "don't care"
> feature, a mutex is problematic:

I don't know who's advertising that "don't care" use of shared variables
would be "cool" and who's being targetted by this advertising (and I
don't even want to know) but I don't share this opinion. This applies
equally to single-threaded and multi-threaded applications. A mutex is a
synchronisation primitive useful for implementing userspace inter-thread
communication facilities (this is a bit too general).

> the programmer should make sure contention is exceptional and there is
> no risk of dead-lock.

Mutexes (or any other kind of lock) should usually be uncontended if
performance is considered important. It's often not necessary that
threads hold more than one mutex at the same time. In case it is, care
must be taken to ensure that they always try to acquire all members of
the shared set of mutexes in the same order to avoid deadlocks. 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Didier Kryn]

Le 25/07/2016 18:06, Steve Litt a écrit :

Complexity has costs that must be paid. Before including any
complexity, I ask myself "can I pay the freight?" Can I afford the
decreased repairability? Can I afford the decreased readability? Am I
ready to document how it works, so a well meaning future maintenance
programmer knows which variables are out of bounds for him to change?

And if I*can*  afford it, is that expense needed? Would things like
forking be as expensive? On a web server handling thousands of
connections, the answer is "probably." On my home workstation, the
answer is "of course not."


I think I am doing the same carefull analysis as you before 
starting to write an application.


Note that, for the case of a web server, different groups have made 
different choices. AFAIK Apache runs one thread per client while Nginx 
uses epoll() to serve multiple clients per thread. Nginx has the 
reputation to have a much smaller footprint and to be faster.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Steve Litt]

On Fri, 22 Jul 2016 12:21:00 -0400
Brian Nash  wrote:

> This describes a problem I used to have perfectly.
> 
> For example, when I discovered multithreading, all my programs used it
> in some way, even when it was unnecessary.
> 
> This might be the root of all the problems we are facing with
> computers today: If we see a cool new feature, we have to find some
> way to use it.

Brian's branch of this thread later went on to spawn discussions of
mutexes, closures, and other stuff. But I'd like to bring it back to
Brian's mention of multithreading. By agreeing with him...

I've never written any multithreading code in my life. Some might
attribute that to my not knowing how (and in fact I don't know how).
But those of you who know me know I never let not knowing how stop me
from getting the necessary things done.

No, the real reason I don't write multithreading code is because it's
complex. Everything involved must be thread safe. It must be written
right. And it's quite a bit more complex than other forms of
multitasking, such as those depending on separate processes.

Complexity has costs that must be paid. Before including any
complexity, I ask myself "can I pay the freight?" Can I afford the
decreased repairability? Can I afford the decreased readability? Am I
ready to document how it works, so a well meaning future maintenance
programmer knows which variables are out of bounds for him to change?

And if I *can* afford it, is that expense needed? Would things like
forking be as expensive? On a web server handling thousands of
connections, the answer is "probably." On my home workstation, the
answer is "of course not."

In a lot of cases, worrying about extra processes is a lot like
worrying about your car's fuel economy and what will happen to it if
you let your car's alternator charge your cell phone.

In summary: Complexity has a cost. Be cost conscious.

SteveT

Steve Litt 
July 2016 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Jaromil]

On Mon, 25 Jul 2016, Didier Kryn wrote:

> Le 25/07/2016 00:55, Steve Litt a écrit :
> >On Sun, 24 Jul 2016 23:30:47 +0200
> >Didier Kryn  wrote:
> >
> >>Le 24/07/2016 22:37, Jaromil a écrit :
> >>>nowadays the closures paradigm (basically fifo pipes of pointers to
> >>>stateless functions) is used much more than all that mutex and
> >>>semaphore old stuff. i.e. golang adopted closures since the
> >>>beginning with great success.
> >>>
> >>>ciao
> >>  Don't know what a closure is, although I heard of it long ago on
> >>this list. According to Wikipedia, it is "a record containing a
> >>function and its environment".
> >Hi Didier,
> >
> >I've never encountered closures as described by Jaromil, but they're a
> >pretty handy thing easily done in many languages, with Lua leading the
> >list. Here's something that might help explain a little bit:
> >
> >http://troubleshooters.com/codecorn/lua/luaclosures.htm
> 
> Thanks, Steve. It confirms my further reading of Wikipedia's article.
> 
> In languages like C, C++ or Ada, it is impossible to use a function to
> create a closure, because they store variables local to the subprogram (then
> creator function) in the stack.

In C++ is possible, made easier using the "Factory" approach

we have this implemented in FreeJ

https://github.com/dyne/FreeJ/blob/aa73398f752ced835d57e3012866512d55de252d/src/include/closure.h

This can be done also in C, but I never need it there. The new C++11
standard makes it even easier with the introduction of lambda
functions.

I've been always very intrigued by concurrency stuff BTW.

nowadays, I'm get all warm and cuddly whenever I get to spend time
with Prismatic Plumbing https://github.com/plumatic/plumbing and
Clojure in general has some really amazing things. I can well
understand the passion for Ada here and think you may well like it.



ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Didier Kryn]

Le 25/07/2016 00:55, Steve Litt a écrit :

On Sun, 24 Jul 2016 23:30:47 +0200
Didier Kryn  wrote:


Le 24/07/2016 22:37, Jaromil a écrit :
  

nowadays the closures paradigm (basically fifo pipes of pointers to
stateless functions) is used much more than all that mutex and
semaphore old stuff. i.e. golang adopted closures since the
beginning with great success.

ciao

  Don't know what a closure is, although I heard of it long ago on
this list. According to Wikipedia, it is "a record containing a
function and its environment".

Hi Didier,

I've never encountered closures as described by Jaromil, but they're a
pretty handy thing easily done in many languages, with Lua leading the
list. Here's something that might help explain a little bit:

http://troubleshooters.com/codecorn/lua/luaclosures.htm
  


Thanks, Steve. It confirms my further reading of Wikipedia's article.

In languages like C, C++ or Ada, it is impossible to use a function 
to create a closure, because they store variables local to the 
subprogram (then creator function) in the stack. It is well known that 
Java allocates everything from the heap, making this easier.


However there are tricks to do it in really many languages:
https://rosettacode.org/wiki/Closures/Value_capture

In Ada this resorts to instantiate a special type of object for 
every closure and then initialize it by a special kind of invocation. 
This special object, behind the scene, contains a mutex :-(, but this 
one could cause contention only when initializing the closure, which has 
no reason to happen. Nevertheless it looks contorted.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Hendrik Boom]

On Sun, Jul 24, 2016 at 11:30:47PM +0200, Didier Kryn wrote:
> Le 24/07/2016 22:37, Jaromil a écrit :
> >On Sun, 24 Jul 2016, Rainer Weikusat wrote:
> >
> >>Didier Kryn  writes:
> >>>Le 22/07/2016 18:21, Brian Nash a écrit :
> For example, when I discovered multithreading, all my programs used it
> in some way, even when it was unnecessary.
> >>>I sometimes use multithreading, but never mutexes. Mutex can be
> >>>harmless if there's only one. Otherwise better use select()/poll() or
> >>>you'll waste time or even dead-lock. It's amazing how the old select()
> >>>paradigm is so much better than the modern mutex. I see mutex as an
> >>>invention to relieve the programmer from thinking.
> >>One of the advantages of having more than one thread of execution
> >>running in the same address space is that these can communicate with
> >>each other without going through the kernel. And 'a mutex' is just a
> >>basic primitive for implementing this.
> >nowadays the closures paradigm (basically fifo pipes of pointers to
> >stateless functions) is used much more than all that mutex and
> >semaphore old stuff. i.e. golang adopted closures since the beginning
> >with great success.
> >
> >ciao
> 
> Don't know what a closure is, although I heard of it long ago on this
> list. According to Wikipedia, it is "a record containing a function and its
> environment". I'm not sure it is different of a method associated to an
> object - there are subtelties here.

That is indeed the way it is implemented in the OO language Sather.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Rainer Weikusat]

Didier Kryn  writes:
> Le 24/07/2016 22:31, Rainer Weikusat a écrit :
>> Didier Kryn  writes:
>>> Le 22/07/2016 18:21, Brian Nash a écrit :
 For example, when I discovered multithreading, all my programs used it
 in some way, even when it was unnecessary.
>>> I sometimes use multithreading, but never mutexes. Mutex can be
>>> harmless if there's only one. Otherwise better use select()/poll() or
>>> you'll waste time or even dead-lock. It's amazing how the old select()
>>> paradigm is so much better than the modern mutex. I see mutex as an
>>> invention to relieve the programmer from thinking.
>> One of the advantages of having more than one thread of execution
>> running in the same address space is that these can communicate with
>> each other without going through the kernel. And 'a mutex' is just a
>> basic primitive for implementing this.
>
> I thought mutexes were implementing through a kernel object known
> as futex.

Sleeping on a contended mutex is implemented in this way. But that's
supposed to be an exceptional case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Steve Litt]

On Sun, 24 Jul 2016 23:30:47 +0200
Didier Kryn  wrote:

> Le 24/07/2016 22:37, Jaromil a écrit :
 
> > nowadays the closures paradigm (basically fifo pipes of pointers to
> > stateless functions) is used much more than all that mutex and
> > semaphore old stuff. i.e. golang adopted closures since the
> > beginning with great success.
> >
> > ciao  
> 
>  Don't know what a closure is, although I heard of it long ago on 
> this list. According to Wikipedia, it is "a record containing a
> function and its environment".

Hi Didier,

I've never encountered closures as described by Jaromil, but they're a
pretty handy thing easily done in many languages, with Lua leading the
list. Here's something that might help explain a little bit: 

http://troubleshooters.com/codecorn/lua/luaclosures.htm
 
SteveT

Steve Litt 
July 2016 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Didier Kryn]

Le 24/07/2016 22:37, Jaromil a écrit :

On Sun, 24 Jul 2016, Rainer Weikusat wrote:


Didier Kryn  writes:

Le 22/07/2016 18:21, Brian Nash a écrit :

For example, when I discovered multithreading, all my programs used it
in some way, even when it was unnecessary.

I sometimes use multithreading, but never mutexes. Mutex can be
harmless if there's only one. Otherwise better use select()/poll() or
you'll waste time or even dead-lock. It's amazing how the old select()
paradigm is so much better than the modern mutex. I see mutex as an
invention to relieve the programmer from thinking.

One of the advantages of having more than one thread of execution
running in the same address space is that these can communicate with
each other without going through the kernel. And 'a mutex' is just a
basic primitive for implementing this.

nowadays the closures paradigm (basically fifo pipes of pointers to
stateless functions) is used much more than all that mutex and
semaphore old stuff. i.e. golang adopted closures since the beginning
with great success.

ciao


Don't know what a closure is, although I heard of it long ago on 
this list. According to Wikipedia, it is "a record containing a function 
and its environment". I'm not sure it is different of a method 
associated to an object - there are subtelties here. However I imagine 
the inter-thread synchronization stuff here is the pipes. I implemented 
a pipe object in Ada a few years ago to synchronize two tasks; if it was 
a closure it would be by chance :-)


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Didier Kryn]

Le 24/07/2016 22:31, Rainer Weikusat a écrit :

Didier Kryn  writes:

Le 22/07/2016 18:21, Brian Nash a écrit :

For example, when I discovered multithreading, all my programs used it
in some way, even when it was unnecessary.

I sometimes use multithreading, but never mutexes. Mutex can be
harmless if there's only one. Otherwise better use select()/poll() or
you'll waste time or even dead-lock. It's amazing how the old select()
paradigm is so much better than the modern mutex. I see mutex as an
invention to relieve the programmer from thinking.

One of the advantages of having more than one thread of execution
running in the same address space is that these can communicate with
each other without going through the kernel. And 'a mutex' is just a
basic primitive for implementing this.



I thought mutexes were implementing through a kernel object known 
as futex. Certainly optimised for speed, I agree. But the gain is 
significant only if you use it intensively, which might denote a badly 
written program, and you soon incur the risk of loosing a huge amount of 
time as soon as a thread contains more than one of those.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Jaromil]

On Sun, 24 Jul 2016, Rainer Weikusat wrote:

> Didier Kryn  writes:
> > Le 22/07/2016 18:21, Brian Nash a écrit :
> >> For example, when I discovered multithreading, all my programs used it
> >> in some way, even when it was unnecessary. 
> >
> > I sometimes use multithreading, but never mutexes. Mutex can be
> > harmless if there's only one. Otherwise better use select()/poll() or
> > you'll waste time or even dead-lock. It's amazing how the old select()
> > paradigm is so much better than the modern mutex. I see mutex as an
> > invention to relieve the programmer from thinking.
> 
> One of the advantages of having more than one thread of execution
> running in the same address space is that these can communicate with
> each other without going through the kernel. And 'a mutex' is just a
> basic primitive for implementing this.

nowadays the closures paradigm (basically fifo pipes of pointers to
stateless functions) is used much more than all that mutex and
semaphore old stuff. i.e. golang adopted closures since the beginning
with great success.

ciao



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Rainer Weikusat]

Didier Kryn  writes:
> Le 22/07/2016 18:21, Brian Nash a écrit :
>> For example, when I discovered multithreading, all my programs used it
>> in some way, even when it was unnecessary. 
>
> I sometimes use multithreading, but never mutexes. Mutex can be
> harmless if there's only one. Otherwise better use select()/poll() or
> you'll waste time or even dead-lock. It's amazing how the old select()
> paradigm is so much better than the modern mutex. I see mutex as an
> invention to relieve the programmer from thinking.

One of the advantages of having more than one thread of execution
running in the same address space is that these can communicate with
each other without going through the kernel. And 'a mutex' is just a
basic primitive for implementing this.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Simon Walter]

On 07/23/2016 06:01 PM, Didier Kryn wrote:

Le 23/07/2016 10:49, Simon Walter a écrit :

On 07/23/2016 05:42 PM, Didier Kryn wrote:

Le 22/07/2016 18:21, Brian Nash a écrit :

For example, when I discovered multithreading, all my programs used it
in some way, even when it was unnecessary.


I sometimes use multithreading, but never mutexes. Mutex can be harmless
if there's only one. Otherwise better use select()/poll() or you'll
waste time or even dead-lock. It's amazing how the old select() paradigm
is so much better than the modern mutex. I see mutex as an invention to
relieve the programmer from thinking.


Really? I must be pretty stupid because I have think extra hard when
using mutexes... :(


Sorry if I hurted you. Maybe you thought hard to understand how to
not dead-lock.



No worries. I am just trying to make a joke. As you can see, I am not so 
funny. ;)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Didier Kryn]

Le 23/07/2016 10:49, Simon Walter a écrit :

On 07/23/2016 05:42 PM, Didier Kryn wrote:

Le 22/07/2016 18:21, Brian Nash a écrit :

For example, when I discovered multithreading, all my programs used it
in some way, even when it was unnecessary.


I sometimes use multithreading, but never mutexes. Mutex can be harmless
if there's only one. Otherwise better use select()/poll() or you'll
waste time or even dead-lock. It's amazing how the old select() paradigm
is so much better than the modern mutex. I see mutex as an invention to
relieve the programmer from thinking.


Really? I must be pretty stupid because I have think extra hard when 
using mutexes... :(


Sorry if I hurted you. Maybe you thought hard to understand how to 
not dead-lock.


The principle is to protect shared variables in such a way that you 
can then roll every thread as if it was running alone - this is what I 
meant by "relieve from thinking". With select() you must keep in mind 
the interactions between the threads, and all your program is organized 
around these interactions, with only one wait point per thread for all 
possible events; therefore no dead-lock.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Simon Walter]

On 07/23/2016 05:42 PM, Didier Kryn wrote:

Le 22/07/2016 18:21, Brian Nash a écrit :

For example, when I discovered multithreading, all my programs used it
in some way, even when it was unnecessary.


I sometimes use multithreading, but never mutexes. Mutex can be harmless
if there's only one. Otherwise better use select()/poll() or you'll
waste time or even dead-lock. It's amazing how the old select() paradigm
is so much better than the modern mutex. I see mutex as an invention to
relieve the programmer from thinking.


Really? I must be pretty stupid because I have think extra hard when 
using mutexes... :(

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Didier Kryn]

Le 22/07/2016 18:21, Brian Nash a écrit :

For example, when I discovered multithreading, all my programs used it
in some way, even when it was unnecessary. 


I sometimes use multithreading, but never mutexes. Mutex can be harmless 
if there's only one. Otherwise better use select()/poll() or you'll 
waste time or even dead-lock. It's amazing how the old select() paradigm 
is so much better than the modern mutex. I see mutex as an invention to 
relieve the programmer from thinking.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[Brian Nash]

This describes a problem I used to have perfectly.

For example, when I discovered multithreading, all my programs used it
in some way, even when it was unnecessary.

This might be the root of all the problems we are facing with computers
today: If we see a cool new feature, we have to find some way to use it.

I'm guessing it's just part of the geek mentality.
It would also explain why the  tag went viral the moment someone
discovered it.

Perhaps there should be some sort of PSA about this for new programmers.

On Wed, Jul 20, 2016 at 03:20:50PM -0400, Steve Litt wrote:

Hi all,

I just found out about Wirth's Law:

https://en.wikipedia.org/wiki/Wirth%27s_law

Hey, I live in the 21st century, so I don't try to optimize out a
kilobyte at a time. But I'm also not blind, so I know that Openbox plus
dmenu is a whole lot quicker and snappier, even on modern computers,
than KDE, Gnome or Unity.

LOL, there's a certain mindset:

* Look at all this room in the new house. Better buy some furniture to
 fill it up.

* Look at all the money in my bank account. I'd better start spending.

* Look at all the RAM and CPU in my computer. I'd better get some
 programs that use it all.

* Look at this simple operating system on this powerful, capable
 hardware. I'd better make more complex software because I can.

SteveT


--
Some mistakes are too much fun to only make once.


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wirth's law

[emninger]

Am Wed, 20 Jul 2016 22:40:11 +
schrieb Steve Litt :

Hi Steve!

> I just found out about Wirth's Law:
>
> [ . . . ]
>
> * Look at all the money in my bank account. I'd better start spending.
> [ . . . ]

I remember this theory/law already mentioned in the eighties in a
genius Apple II GS discussion group. But anyway ... it's nice :) :)

But i disagree on your money metaphor: Living in the times we're living
i'd say "carpe diem" (= spend your money now and best for what you need
and don't give it to the banks) might be indeed the better advice.

If the times get harder we could try to elevate goats and tomatoes ;)

Sorry for the digression.

Cheers!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng