3 ms·

There is a single OS call to put the current thread to sleep; I mentioned it much earlier - a single pthread_mutex_t per Thread NOT per lock Those are not any

by xxs 5y ago

There is a single OS call to put the current thread to sleep; I mentioned it much earlier - a single pthread_mutex_t per Thread NOT per lock Those are not any part of the developer capability to manage, aside starting the thread (and locking on it). The mutex is released with the thread, itself; Technically hotspot impl java does not ever releases them back to the OS but keeps a free-list. The thread is a lot larger OS resource as well. No new OS resources are exhausted by the OS b/c of the extra locking. >The claim that LockSupport, which is calling the OS is not a wrapper is bogus. Of course it does call the OS; it happens on the dormant part (w/o an OS call it'd a busy spin), or if a thread needs to be awaken. I said not a 'thin' wrapper. All the locking and queueing mechanism is outside the OS. The major distinction is there is only a single OS primitive per Thread NOT per lock. (Edit: now I see I have spelled thin as 'thing' which is a definite mistake on my part) /* * This is the platform-specific implementation underpinning * the ParkEvent class, which itself underpins Java-level monitor * operations. See park.hpp for details. * These event objects are type-stable and immortal - we never delete them. * Events are associated with a thread for the lifetime of the thread. */ https://github.com/openjdk/jdk/blob/c4c76e2f34f7e709f8b3c960d8c796ff4e2dc4a5/src/hotspot/os/posix/os_posix.hpp https://github.com/openjdk/jdk/blob/c4c76e2f34f7e709f8b3c960... // ParkEvents are type-stable and immortal. // // Lifecycle: Once a ParkEvent is associated with a thread that ParkEvent remains // associated with the thread for the thread's entire lifetime - the relationship is // stable. A thread will be associated at most one ParkEvent. When the thread // expires, the ParkEvent moves to the EventFreeList. https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/hotspot/share/runtime/park.hpp https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225... Edit: My point has always been that locks/monitors/semaphores/etc. dont need any special care in a GC-setup as they can be implemented purely in the language itself, and without special care to release them, and manage them similar to file descriptors. The need to block (become dormant) obviously requires OS calls and support but that part doesn't have to scale with the amount of locks/semaphores/latches/etc. created.

tialaramex 5y ago
> now I see I have spelled thin as 'thing' which is a definite mistake on my part That does make a lot more sense. I agree that what's going on here is not merely a thin wrapper. > My point has always been that locks/monitors/semaphores/etc. dont need any special care in a GC-setup as they can be implemented purely in the language itself And my point was always that you can only depend upon this if you in fact are always using the "implemented purely in the language itself" mechanisms, while plenty of others exist and you might need them - but you can't just treat them as garbage safely. So overall I think we were mostly talking at cross purposes. Actually looking at the Java stuff reminded me of m_ou_se's thread about how big boost::shared_mutex is (it's 312 bytes). Most people who need one of these synchronization primitives only really need the one that costs 4 bytes, but it's hard to keep saying "No" to people who want to add features. They're always confident that everybody will love their feature, at the cost of a little more memory, and it spirals out of control. On most systems the pthread_mutex_t you mentioned is already 40 bytes. A "nightly" Rust can do a 32-byte array with a mutex to protect it, all inside 40 bytes.

by xxs 5y ago

tialaramex 5y ago

> now I see I have spelled thin as 'thing' which is a definite mistake on my part That does make a lot more sense. I agree that what's going on here is not merely a thin wrapper. > My point has always been that locks/monitors/semaphores/etc. dont need any special care in a GC-setup as they can be implemented purely in the language itself And my point was always that you can only depend upon this if you in fact are always using the "implemented purely in the language itself" mechanisms, while plenty of others exist and you might need them - but you can't just treat them as garbage safely. So overall I think we were mostly talking at cross purposes. Actually looking at the Java stuff reminded me of m_ou_se's thread about how big boost::shared_mutex is (it's 312 bytes). Most people who need one of these synchronization primitives only really need the one that costs 4 bytes, but it's hard to keep saying "No" to people who want to add features. They're always confident that everybody will love their feature, at the cost of a little more memory, and it spirals out of control. On most systems the pthread_mutex_t you mentioned is already 40 bytes. A "nightly" Rust can do a 32-byte array with a mutex to protect it, all inside 40 bytes.