Возможно, стоит пояснить разницу между синхронизацией из thread/process-safe и синхронизацией с помощью Lock🤔
Наша задача — заставить разные процессы и потоки обращаться к базе данных (или любым другим ресурсам) последовательно. Чтобы не случилось так называемого race condition, то есть состояние гонки. Это когда разные потоки или процессы пытаются одновременно что-то сделать с одним и тем же ресурсом.
В этом случае нам нужна какая-то логика ограничения. Пока один процесс не завершил своё действие, другие не могут получить доступ к ресурсу.
Так вот, thread-safe и process-safe означает что отдельно взятые операции записи в БД гарантированно будут последовательны. Запросы из разных процессов или потоков выстроятся в очередь и не будут мешать друг другу. Лучше всего когда этот блок реализован на уровне БД в виде атомарных операций или ещё как-то.
Но зачем нам тогда еще дополнительный Lock?
Этот способ синхронизации используется когда процесс никак не укладывается в одно действие и должен сделать множество операций прежде чем дать доступ следующему. В этом случае процесс ставит некий глобальный Lock на ресурс и никто другой, даже получив законное право на доступ, не может ничего сделать. Все ждут пока этот Lock не будет снят.
Это решается на уровне приложения и правильность реализации полностью в вашей ответственности. Например, если забыли разблокировать или сделали перекрёстный Lock (Deadlock как на картинке), то всё зависнет в бесконечном ожидании.
#basic
Image to Text OCR is a utility website made by Alejandro Akbal for extracting text from any image using #OCR.
This tool was made for those moments where you take a photo of some text and wish you could have it digitally.
https://github.com/AlejandroAkbal/Image-to-Text-OCR
Online: https://image-to-text-ocr.netlify.app/
🦉 LightOnOCR-1B: новая быстрая OCR-модель от LightOn
Модель дистиллирована из Qwen2-VL-72B-Instruct и обучена на корпусе из 17.6 млн страниц / 45.5 млрд токенов.
🔥 Главное:**
-1 B параметров
- позволяет обрабатывать 5.7 страниц/с на одном H100 (это примерно ≈ 493 000 страниц за день)
- Распознаёт таблицы, формы, уравнения и сложные макеты
- 6.5× быстрее dots.ocr, 1.7× быстрее DeepSeekOCR
- Расходы < $0.01 за 1000 страниц A4
📊 Качество (Olmo-Bench):
- Превосходит DeepSeekOCR
- Сопоставима с dots.ocr (при этом модель в 3 раза меньше по весу)
- +16 пт к Qwen3-VL-2B-Instruct
Эта моделька - отличный баланс качества, скорости и стоимости.
🟢Модель 1B: https://huggingface.co/lightonai/LightOnOCR-1B-1025
🟢Модель 0.9B (32k): https://huggingface.co/lightonai/LightOnOCR-0.9B-32k-1025)
🟢Блог LightOn:https://huggingface.co/blog/lightonai/lightonocr
🟢Демка: https://huggingface.co/spaces/lightonai/LightOnOCR-1B-Demo
@ai_machinelearning_big_data
#ocr#ml
📄 DeepSeek-OCR - модель для распознавания текста 🔍
DeepSeek выпустили мощную OCR-модель, способную преобразовывать изображения документов прямо в Markdown или текст.
Что умеет:
- Распознаёт текст на изображениях и в PDF
- Работает с документами, таблицами и сложными макетами
- Поддерживает разные режимы: Tiny, Small, Base, Large
- Оптимизирована под GPU (PyTorch + CUDA 11.8)
- MIT-лицензия — можно свободно использовать и модифицировать
DeepSeek-OCR достигает высокой точности и эффективности за счёт компрессии визуальных токенов. На Omnidocbench - лучшая точность при минимуме визуальных токенов, превосходит другие OCR-модели по эффективности и скорости.
🟠HF: https://huggingface.co/deepseek-ai/DeepSeek-OCR
🟠Github: https://github.com/deepseek-ai/DeepSeek-OCR
🟠Paper: https://github.com/deepseek-ai/DeepSeek-OCR/blob/main/DeepSeek_OCR_paper.pdf
@ai_machinelearning_big_data
#ocr#DeepSeek