Re: [dylan] Stream locking (was: Method combinations as a design pattern for locking)

Hannes Mehnert <[email protected]> Wed, 18 Dec 2013 13:24:04 +0100
Newsgroups gmane.comp.lang.dylan.gwydion.devel
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Hi,

there's a thread from the beginning of this year on the same topic.
Not sure why this is brought up so often.

In that discussion, I appreciate Bruce Hoult's comment:
> I think that, except in a very few cases such as stderr, multiple
threads
> writing to the same stream is at the least bad program design and
probably
> a bug.

> I would make the default to be non-locked, but with detection and
warning
> of writing from multiple threads, if cheap to do. e.g. store and
> compare the thread IDs or TLS pointers or something. Even the stack
> pointer
would
> suffice, if you can get the stack base and limit for the current
> thread (only has to be one once per non-locking stream, the first
> time it's
used).

And while I'm happy with the current code, having to explicitly
annotate streams which do not require a lock, I'd be ok to remove
these by-default locks if there is a warning implemented as Bruce
proposes above.

On 12/18/2013 02:59, Bruce Mitchener wrote:
> Unfortunately, a couple of years ago, some locks were introduced to
> the streams library and I suspect that that has led to some issues
> over time. An example of that is that in the typical case of
> creating a <string-stream> for printing some data to it, we have to
> be sure that we create it unlocked (like in the date code in the
> system library), otherwise it can become a visible overhead when
> profiling.

I consider these stream locks to be easy catches during profiling.

I also do not understand why you want to remove (in your branch) both
the init-value for the private-stream-lock-value slot of
<basic-stream>, as well as the calls to with-stream-locked from within
io? Does the test whether stream-lock is non-false (in lock-stream)
lower the performance in a significant way?
Aren't there more serious performance bottlenecks in the streams library?


Just my 2 cents,

Hannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQIcBAEBCQAGBQJSsZPkAAoJELyJZYjffCjuD1YQAL1B5ec8VsWmokHLRpBFN1nP
OiyHlYoZFxS5auFWNNBcxTDTrGwPmNcvOIm1O9utAEk1D3x/oIHcnvL56c+3axjt
gfyn2uMBWHNZDzEYqQtZDTjp+mBXNCqCnns23yUU73hwgyqPCJybgygxrtODBd7D
EUF4L3rDM33+XetdczPCMLbc4E70egOBP1y86S/pHfyeICZWw00O/eMkSscZeJWP
h8/f+vp1vjiIQ7kkZ4YcByDqrUbH7U9OOxyFlFrpune3C8MD+W9cxZGXeEPZ4AuI
fgVhqvksaklk0jeOaiVjvzQFylmkJ/zkKFcIIdn8dQBgrUgxRQtQ7vfsHjIAYt+3
g/dnQ8WNCYNRwyzVuwtKhYn105TAGH6X5F3ZHJO+6tfYzq5bbQWdQy6iPxvb1NuG
BHTqGgx7/eSYIViegvdSPi7MY4M561cCOiI3aeN94moo/sFnlpnHmk/w2j49+L+H
361ZDzUlQXJ3mIP19goQC/oT9onP1YQygYlcrssCi5eJUIt2EkNHtZUOKUUfeuO/
4cCCVWVVmnGgg8ucKuniDztxU/0m3yqS+n0+wfeYPFgyjajTVACAXpZKS6wfqlN9
HekQSKLSfJq9bNt3lTIaMx3sJlLbLlGhX3SXnwEOsbZu/qeGFLRp3XCxuPk47Krs
yZEre1qno1eIhrf0Laxj
=kR6O
-----END PGP SIGNATURE-----
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers