scivey7's comments

Apologies for not contributing anything meaningful to the overall discussion here... but this is one of the best things I've read all day.

It's never even occurred to me to typedef a function like this, and now that I think about it I'm not sure why. Your way is a lot clearer. Thanks for the tip.

Do you remember where you picked this up? Any particular book or codebase?

This is something I haven't found an ideal solution for yet. There are existing iOS PDF readers with reflow, but each seems to have its own issues.

To echo what others have said, this is an actual pain point and I'm very willing to spend money on a solid solution. I've bought a few different PDF readers just on the chance their reflow would be better than what I've found elsewhere.

So I clicked on your link pretty ready to throw money at you, but I'm not sure what I'm looking at. Is this an iOS app? Android app? It seems like some kind of service, since it wants me to login, but I can't tell.

Consider working on the messaging and then reposting this. There's definitely a market.

In an ideal world yes, but TSX has some significant limitations. andikleen2 has mentioned some of those in his comments.

TSX is somewhat unpredictable as a general tool, and there are difficulties with e.g. knowing which transactions are even feasible. Generic "complicated transactional operations" also make lock-based fallbacks very difficult and expensive, which andikleen2 also touched on.

After experimenting with more general use of TSX, I very quickly came not to trust it. So the real motivation here is to tame TSX's unpredictability by using it in a very controlled way.

TSX simply isn't suitable yet for complicated transactions, but just providing hardware-level support for multi-CAS is already a big deal.

Your feedback has been very helpful. Do you mind if I ask you for more advice down the line?

You're correct: the limits on transaction size are unknown. That's mentioned in the documentation here https://github.com/scivey/xact/blob/master/docs/api/n_way.md

TSX is a black box in many ways, and I think we can expect its behavior to change over time and across implementations.

I'm not enforcing an arbitrary limit on transaction size because the primary goal is just to expose a simple C++ API to fundamental primitives. The TSX intrinsics are much more difficult to work with, and assembly is painful.

If that seems like a cop-out, consider that DCAS is effectively a transaction size of two. TSX appears to handle this trivially. Yet DCAS is already a very powerful operation, and is useful in itself.

As the docs emphasize, the goal is not general transactions but extended versions of the small atomic operations already in common use.

In terms of safety and opinionatedness, I think of XACT like a library of locking primitives: pthread_spinlock_t is very useful, but it will not stop you from introducing deadlocks. Likewise, I won't stop you from attempting transactions that are too large to succceed on current hardware. Ultimately, I expect anyone using this to test and benchmark their own code on their own machines.

Beyond a certain size, transactions will be less and less valuable even if they can be successfully completed: if you're attempting 64-way CAS, benchmarks are probably going to guide you toward traditional locking anyway.

Agreed that the basic "store to 8 locations" API would need tweaking to allow locking.

Re: adding a counter into the read set, I think the new generalized API here will support that out of the box: https://github.com/scivey/xact/blob/master/docs/api/generali...

Thoughts?

I'm aware of the issue with non-terminating transactions, though I wasn't aware of the role played by page faults -- thanks for adding that detail.

Looking back over the readme, I can see how the loops used in the examples are a little misleading.

This is mostly a documentation issue: the core XACT code doesn't use infinite retry loops, and actually does not retry transactions at all. As with std::atomic, the goal is to provide a basic primitive and leave retry / backoff / etc. up to the user. This is especially important with lock-based fallbacks, as I can't pick one perfect lock to fit everyone's workload.

I ended up dropping retries because I ran into so many never-ending transactions in my early experiments with TSX. That was also my motivation for limiting the transactions to as few locations as possible.

I'm just now starting to reexamine this and add some configurable retry logic back in -- e.g. the retry policy here is used in some test code: https://github.com/scivey/xact/blob/master/include/xact/atom...

As to the difficulty of protecting any memory touched in a transaction under a locking scheme: that kind of problem is exactly why XACT is focused on CAS-like operations on relatively limited sets of memory addresses.

Can you elaborate on the global lock? What's the motivation there?

Multiple keys seem to be fine.

I haven't seen performance issues, but it's a relatively small deployment in the scheme of things. There are also existing solutions for caching here. NSCD seems to be the go-to for caching LDAP query results directly. Alternately, you could cache credentials at the PAM level with pam-ccreds (Debian package name).

I just recently had to solve this problem. I ended up using this Python package: https://github.com/jirutka/ssh-ldap-pubkey

Xr